Общими усилиями переходим на GIT. Репо с историей перетащить удалось, но всё в "плоском виде" ветки и тэги чисто в отдельных каталогах как и транк.

Как проще из всего этого сделать "нормальное дерево"?

Ну и вообще как вы работаете с Гитом?

На сервере нужно иметь обязательно "bare repo" - с этим уже накололись. А на клиенте как делаете?

Нужно чтобы структура каталогов осталась старой. Проблема в том что репо относительно много, а проекты должны иметь определенную структуру каталогов.

Поэтому делаем на клиенте тоже "bare repo" как клон с основного, а с него уже "рабочий бранч" куда нужно.

Мы не коллеги часом? Сегодня полдня убил на аналогичную задачу. На прошлой работе все это делали "специально обученные люди", здесь же приходится все делать самому и с нуля - и доказывать еще, почему git удобнее.

Что значит "на клиенте"?

Что значит "на клиенте"?

ну тот кто к серверу цепляется, например комп разработчика.

Сегодня полдня убил на аналогичную задачу.

Только полдня? Маловато . Сегодня весь день только Гитом и занимались

Что выяснил - о переносе каталогов заботится не нужно, главное больше ничего не менять. Тэги и бранчи прийдётся видимо отследить по "названиям" коммитов

Вот что понравилось

https://habrahabr.ru/post/106912/

https://habrahabr.ru/post/174467/

Я стараюсь использовать rebase flow, потому что ненавижу спагетти при выводе git log --graph

Я думал, эти времена уже давно в прошлом.

На сервере нужно иметь обязательно "bare repo" - с этим уже накололись. А на клиенте как делаете?Нужно чтобы структура каталогов осталась старой. Проблема в том что репо относительно много, а проекты должны иметь определенную структуру каталогов.Поэтому делаем на клиенте тоже "bare repo" как клон с основного, а с него уже "рабочий бранч" куда нужно.

Тоже не понимаю. На клиенте и сервере структура репо одинаковая. Клиент - это копия сервера.

Из практических советов:

- использовать хороший diff tool. Если есть Beyond Compare - очень хорошо. Я пользуюсь связкой WinMerge + P4Merge.

- настроить алиасы для комфортной работы в консоли. Мои ленивые коллеги до сих пор пишут git status вместо git st или git log --graph --online вместо git glo.

- использовать rebase before push

Не Вы один, коллега. Сам был, так сказать, крайне удивлён.

К серверу цепляется?

Нет, Вы просто клон удаленного делаете в любом удобном месте, хоть десяток. Нет никаких клиентов и прицепов.

настроить алиасы для комфортной работы в консоли

Как это работа в консоли может быть комфортной? Для меня комфортна исключительно работа с мышкой.

А Beyond Compare уж фиг его знает сколько лет пользую. Проблема была как его студии скормить. Нигде нет настроек. Перепробовал несколько .gitconfig пока правильный не нашел.

Но удобство пользования всё равно гораздо хуже.

Раньше в студии при коммите можно было глянуть отличия по интересующим файлам. Для гита в студии подобной возможности пока не нашел.

Насчёт rebase можно сейчас холивар развести. Я против безусловного rebase.

Спор известен и давишен. Но кому вишня, а кому и крыжовник.

Вы по SSH рельсы прокладывали? Или?

Надо было импортировать через git svn - тогда бы ветки и бранчи были бы корректно замаплены. Если структура была стандартной, как trunk/branches/tags, то это просто ключ -

TortoiseGit для винды. Visual Studio должен работать из коробки

GitExtensions ещё можно глянуть. Довольно неплохой GUI для винды.

К серверу цепляется?

Это я просто с сетями последнее время сижу...

Пока вот что выяснил - может еще кому "переходящему" пригодится.

Гит имеет два типа репозитория: "голый" (bare) и с рабочей копией. Отличия очень важные. Для того чтобы несколько человек могли коммитится в репозиторий он должен быть обязательно "голым".

Кроме того рабочую копию с "голого" репозитория можно разместить в любом каталоге и таких копий может быть достаточно много.

Визуал студия может работать только с репозиториями у которых есть рабочая копия.

Различать эти случаи довольно просто:

- "голый" репозиторий имеет стандартную структуру каталогов, в котором вашего проекта никак не видно

- репозиторий с рабочей копией имеет папку ".git".

- рабочая копия без репозитория имеет файл ".git".

Гит не работает с файловой структурой как свн, поэтому перемещать файлы и каталоги можно без опаски. Хотя не рекомендуют перемещение и изменение одновременно.

Понятие "веток" и "тэгов" имеется также, хотя это просто метки к коммитам.

"Стандарт работы" следующий:

- создается "голый" репозиторий доступный для всех разработчиков.

- каждый разработчик делает себе его локальную копию - так называемый процесс клонирования.

- после клонирования определенная ветка может быть автоматом скопирована как рабочя копия.

- Все изменения делаются в рабочей копии. Изменения можно просмотреть и переместить все или некоторые в специальное временное хранилище - staging area

- Изменения из staging area можно сохранить в локальной копии репозитория.

- Изменения из локального репозитория нужно переслать в общий репозиторий.

- Изменения из общего репозитория можно стащить в локальный.

Вы по SSH рельсы прокладывали? Или?

не, пока просто папочки на обычном файловом сервере. С Гит сервером пока проблемы.

Надо было импортировать через git svn

Вроде так народ и делал, но получилась одна мастер ветка с полной структурой каталогов "trunk/branches/tags"

Одну ветку "вынес", но не получилось туда перенести все коммиты из этой ветки.

TortoiseGit для винды. Visual Studio должен работать из коробки

Git Extention мне больше понравился, хотя у него часто вылет по нулевому указателю происходит.

Студия да, работает из коробки, но по сравнению с "анком" намного фиговей и не поддерживает рабочие копии вне репозитория.

А я было уж обрадовался, что не надо будет "лишнего" в проектах держать.

Я тоже не догматик :) Например, feature branches можно и мержить. Но rebase before push - обязательно на мой взгляд.

Как это работа в консоли может быть комфортной? Для меня комфортна исключительно работа с мышкой.

Ты просто не познал дзен. Git - это не svn.

Некоторые вещи удобнее в консоли, некоторые в гуе. Например, я обычно коммичу в IDE, а все остальное делаю в консоли. По моему опыту намного меньше косяков.

Господи, какой геморрой. Поставь уже себе нормальный сервер типа Bitbucket и забудь этот кошмар.

+1. Консоль для гита самое то. В гуях я историю смотрю и cherry-pick в том же SourceTree быстрее получается. Я и коммичу в консоли. А то вечно весь этот гуй себя умнее считает и "помогает". А ты потом сидишь и голову чешешь - как же так получилось, я просто изменения коммитил...

Справедливости ради в идее интеграция сделана очень хорошо. Но консоль все равно лучше :)

Или Gitlab...

Этот еще и бесплатный вроде.

Мне пока консоли достаточно. Единственное, где недостает чего другого - это diff понагляднее увидеть: чего ушло, чего пришло.

WinMerge для диффа и p4merge для 3 way merge.

Tool для 3 way merge - в обязательном порядке.

Некоторые вещи удобнее в консоли

ненавижу консоль еще с детского садика. Первое что делаю в никсах - устанавливаю мс.

Зачем чего-то печать когда можно просто нажать кнопу...

Хотя был когда-то коллега который всё делал только в консоли и пользовал 20 символьные пароли.

Как то он заболел, так фиг знает сколько мучались пока пароль правильно ввели.

Поставь уже себе нормальный сервер типа Bitbucket и забудь этот кошмар

Какой именно кошмар? И что даст сервер?

Базовые концепты то не изменятся.

cherry-pick

А что он делает, что -то пока еще понял.

Хотел вот парочку коммитов с мастера в другую ветку перетащить - не получилось.

Клиент - это копия сервера.

Позволю не согласится.

Во первых, на сервере не может быть рабочей копии.

Во вторых, забрать можно не всё.

А как Вы без сервера хотите все настраивать и запускать? Он нужен в том или ином виде.

А что ты будешь устанавливать, если это продуктивный сервер, и у тебя нет прав? ;)

Ненависть иррациональна, а консоль в данном случае имеет смысл.

Ты точно о Git? По-моему, ты еще не понял, что локальная копия репозитория - это полная копия репозитория на сервере. Естественно, никакой рабочей копии на сервере нет, она там не нужна.

А как Вы без сервера хотите все настраивать и запускать? Он нужен в том или ином виде.

Для git-а? Нет, специальный сервер для git-а не нужен. Сервер удобнее, тот же Bitbucket или gitlab помогают с code review, например, но и без них можно работать. Хоть на самбовской шаре центральный репозиторий клади.

А что он делает, что -то пока еще понял.

"Копирует" коммит. Создает новый коммит, который выполняет такие же изсенения как и "копируемый".

Хотел вот парочку коммитов с мастера в другую ветку перетащить - не получилось.

А что значит "перетащить"? Убрать из мастера и создать в ветке или скопировать в ветку?

А как Вы без сервера хотите все настраивать и запускать?

Создаем "голый" репо в любом доступном для всех месте. Где проблемы для локальной сетки?

А что ты будешь устанавливать, если это продуктивный сервер, и у тебя нет прав?

Если я должен что то устанавливать, то должны дать права...

а консоль в данном случае имеет смысл

А что я не смогу сделать без консоли? Всё есть или в апи или в "эмуляторе консоли"

По-моему, ты еще не понял, что локальная копия репозитория - это полная копия репозитория на сервере.

Может тогда обьясните принцип работы данного ключика?

Ну и вариант, когда коллега залил баальшую ветку которая мне нафиг не нужна. Почему у меня стоит значёк , что информация доступна только на сервере?

Сорри проверять некогда, засылают почти на месяц в командировку.

Создает новый коммит, который выполняет такие же изсенения как и "копируемый".

где именно? В какой ветке?

-->Убрать из мастера и создать в ветке

СВН-вская копия получилась без веток в коммитах, просто идет одна длинная кишка, хотя по файлам видно что изменения исключительно в ветке, да и ветка моя, так именно и делал.

Вообще-то, что Bitbucket, что Github уже в своем роде сервера, которые позволяют делать всевозможные танцы с бубном. Можно на стороне сервера (не git, просто машина в сети) установить тот же Bonobo или другой возможный аналог. И уже с ним устраивать светопреставления, Элисы и Бобы, приватные и публичные ключи.

Плюс по всему что Bitbucket, что Github для продакшн-кода так просто и использовать грешно. Да и корпоративный Bitbucket, например, тоже не в каждом случае можно использовать и не в каждом проекте.

Никаких проблем. Только это не сервер, а обычный удаленный репозиторий получится. Не более. Для полноценного сервера нужен демон на той стороне. Что-то Вы не туда копаете который день :-) А меня упрекали в сроках!

Что-то Вы не туда копаете который день

Стояла задача получить что то рабочее на этой неделе, а не пользовать исключительно сервер.

Ну так это делается одной командой git init -bare. Чего там курить неделю. С настройками демона, да, можно на пару дней зависнуть. Кстати, я Вам давал давеча ссылку - посмотрите видео, рекомендую.

Ни разу не пользовался. Максимальный репо в моей практике был 2 гб (замусоренный бинарниками и прочим), но никаких проблем это не создает в повседневной работе.

Плюс по всему что Bitbucket, что Github для продакшн-кода так просто и использовать грешно.

Вы имеете в виду github.com? Мы упоминали GitLab, а не GitHub.

У нас стоит на локальном сервере полный стэк Atlassian, и мы туда все наши проекты пихаем. Какие причины их не использовать?

Use the --depth option in git clone

Ну, давайте я поясню. Если выстрелить себе в ногу, не надо удивляться что ходить неудобно :)

depth "обрезает" историю. При depth 1 копируется текущее состояние master-а и всё. Никакой информации (вот тут не уверен на 100%, может информация "был коммит с комментарием" и будет, но не будет данных о состоянии проекта в этом коммите) о предыдущих коммитах. Работать с таким - вредительство. Используется в основном для автоматических сборок. Им история не нужна.

Ну и вариант, когда коллега залил баальшую ветку которая мне нафиг не нужна. Почему у меня стоит значёк , что информация доступна только на сервере?

А тут ответ сложнее.

1. Когда мы делаем git clone (без ограничения глубины!) мы копируем всё. (за исключением некоторых настроек, см. --mirror) Но. Локальные ветки не создаются.
Например. На сервере есть master и development после git clone делаем git branch и видим... Только *master. Но стоит сделать git branch -r как мы увидим и origin/master и origin/development.

Если хочется работать с другой веткой просто делаем git checkout development. Это создасть локальную ветку development, которая будет ссылаться на origin/development. Никакие данные при выполнении этой команды с сервера не копируются. Они уже у нас.

Если вы сделали git clone и после этого "стоит значёк , что информация доступна только на сервере" выбросьте нафиг этот гуй. Он тупой.

2. Склонировали репо и работали с ним какое-то время. Коллега заливает на центральную репо свою ветку. Локально у нас про нее нет никакой информации. Мы даже не знаем что она существует. Можно или сделать git fetch (забрать всю новую инфу с сервера, со всеми коммитами, новыми файлами и те пе, может длиться) или можем посмотреть а что там есть на сервере с помощью git ls-remote

Если в этом случае ваш гуй показывает "значёк , что информация доступна только на сервере", то он всё делает правильно. Посмотрел на удаленке и показал, но сам пока что ничего не скачивал.

Создает новый коммит, который выполняет такие же изсенения как и "копируемый".
где именно? В какой ветке?

В текущей.

СВН-вская копия получилась без веток в коммитах, просто идет одна длинная кишка, хотя по файлам видно что изменения исключительно в ветке, да и ветка моя, так именно и делал.

Тут или хреново сконвертировали (git-svn хорошо понимает свн-овские ветки) или есть недопонимание. Если параллельной разработки никогда не было (сделали ветку, поработали в ветке, потом замержили ветку назад в транк, при этом в самом транке никаких новых коммитов не было) то гитовский лог будет выглядеть как линия.
Может так понятнее... Если в svn было

trunk: A - B  -  -  -  F
            \         /
branch:      C - D - E

То в графе коммитов в гите вы увидите A- B - C - D - E - F

Но ветка "branch" будет на месте. Ее HEAD будет показывать на E (а master на F). Хотя не уверен, будет ли F присутствовать. Он в принципе не нужен...

А что говорит git branch -a?

Вообще-то, что Bitbucket, что Github уже в своем роде сервера, которые позволяют делать всевозможные танцы с бубном.

И? Я говорю что можно работать без них.

Плюс по всему что Bitbucket, что Github для продакшн-кода так просто и использовать грешно.

Почему?

Да и корпоративный Bitbucket, например, тоже не в каждом случае можно использовать и не в каждом проекте.

А конкретнее можно? Пример проекта, который нельзя хранить в битбакете не опишите?

GitHub тоже можно купить. Но геморройно. И дорого. И нафиг надо.

Ну так это делается одной командой git init -bare.

Это создается пустой репо.

А в задаче требоваловась пользовать готовые проекты из SVN в Гите.

Работать с таким - вредительство.

Я не говорю, что надо работать. Речь вроде шла, что локальная копия всегда полностью идентична удаленной.

Про всё остальное - не исследовал и в ближайшее время уже не получится.

Если в этом случае ваш гуй показывает "значёк , что информация доступна только на сервере", то он всё делает правильно. Посмотрел на удаленке и показал, но сам пока что ничего не скачивал.

именно этот вариант и имел в виду.

git-svn хорошо понимает свн-овские ветки

не уверен, похоже он знает только одну версию svn

А что говорит git branch -a?

не имею никакого понятия, так как командами не пользуюсь, но все новые ветки (гитовские) и тэги видны, а старые нет.

Пример проекта, который нельзя хранить в....

Концепция начальства следующая - никаких исходников на сторонних серверах.

Ну, например мой текущий проект подпадает под определенный уровень секретности, и по внутренней полиси использовать его даже на корпоративном Bitbucket нельзя. Потому что формально это уже не нами управляемый удаленный сервер.

Имеется в виду установленный у себя на сервере Bitbucket, а не bitbucket.com.

Я не говорю, что надо работать. Речь вроде шла, что локальная копия всегда полностью идентична удаленной.

Ну, тут, похоже недопонимание. После обычного clone (т.е. в 99% случаев) локальная репо содержит те же объекты что и удаленная. Кроме depth есть и другие параметры, ограничивающие что мы копируем. Но всё это очень редко используется. А, да, есть еще LFS... Ну и изменения в удаленной репо не попадают на наш локальный компьютер "автоматически". Их надо сначала скачать.

Ну и именно этот вариант и имел в виду.

Тогда все хорошо. При следующем fetch-е все данные окажутся в локальной репо.

не уверен, похоже он знает только одну версию svn

Можете быть уверены. Последний раз мы свн в гит недели две назад перетаскивали.

не имею никакого понятия, так как командами не пользуюсь,

А зря. Что там вам ваш гуй показывает я не знаю. Да, если вы командами не пользуетесь, как же вы svn мигрировали?

Имеется в виду установленный у себя на сервере Bitbucket

А какой смысл платить 1800 долларов за сервер?

Мнэ... А что вы называете "сторонним сервером"? Если я на своем рабочем компе установлю битбакет, он сторонний сервер или нет?

А какой смысл платить 1800 долларов за сервер?

Ну, лицензия на 10 пользователей стоит 10 долларов. Есть бесплатный гитлаб.

А смысл... Наверное, чтобы соответсвовать

Концепция начальства следующая - никаких исходников на сторонних серверах.

Ну установите себе в том месте, куда только у вашей группы есть доступ, свой собственный битбакет или гитлаб и управляйте на здоровье.

Последний раз мы свн в гит недели две назад перетаскивали

с какой версии СВН? Стараемся без нужды не обновлять, а то иногда получаются "приятные сюрпризы".

А зря. Что там вам ваш гуй показывает я не знаю.

А зачем мне распечатывать все команды, потом их искать - когда всё есть в диалогах и меню.

Я не перетаскивал, но ради интереса попробовал команда не работает.

Эту фигню тоже пробовал http://www.syntevo.com/smartgit/, если бы сразу написали Ява, даже бы и не пробовал. "Голое" репо и то не умеет показывать.

А что вы называете "сторонним сервером"?

Сорри, думал понятно из контекста, что речь идет об простом файл сервере.

Ну, лицензия на 10 пользователей стоит 10 долларов

Подозреваю, что там просто нет текста с "маленькими буквочками", ни разу не видем коммерческого софта за 10 долларов.

Наверное, чтобы соответсвовать

А чем фигова просто "файловая версия"?

Ну так вот на этом и остановились - нужен демон для этого. Настроить же демона - дело дня, двух. Проблема в том, что у нас в SW Pool нет ни одного демона. Мало того, запретили к использованию старый клиент, а насчёт нового молчат. Тут впору вспоминать поговорку, что если бы в аду была бюрократия, она бы была немецкой - на Украине у нас, конечно, тоже было куча проблем при настройке инфраструктуры, но можно и реально было Белых Эльфов уговорить на покупку и демонов, и JIRA, и прочих плюшек. Да, Эльфы долго раскачивались, жались, но понимали, что это все нужно. Здесь же даже до Эльфов не добраться в силу немецкого ретроградства и огромных размеров концерна. Концов нет.

с какой версии СВН?

А вот это не скажу, смотреть надо. Если это сервер еще полностью не отключили... Могу только сказать что первый раз я перетаскивал свн в гит в 2009-м, не помню чтобы у нас там были проблемы с ветками... С тэгами были, да.

А зачем мне распечатывать все команды, потом их искать - когда всё есть в диалогах и меню.

По той простой причине что про команды есть четкое и достаточно точное описание. А что делает каждый гуй когда нажмешь на кнопочку "коммит" обычно описано как "коммитит изменения" а в реальности от "коммитит и пушит" до "сам добавляет все что посчитал нужным в коммит, коммитит, мержит в develop потому что увидел такую ветку и решил что бы используем git flow, добавляет тэг, но делает это через такую жопу что на сервере не срабатывают hook-и", зато со свистелками и перделками.

Плюс когда знаешь команды начинаешь понимать что и насколько просто можно автоматизировать.

Я не перетаскивал, но ради интереса попробовал команда не работает.

Угу. Осталось угадать какая команда и что именно не работает.

git svn clone http://svn/repo/here/trunk

?
Из гуев могу только посоветовать SourceTree. С ним у меня было меньше всего проблем.

Подозреваю, что там просто нет текста с "маленькими буквочками", ни разу не видем коммерческого софта за 10 долларов.

Посмотрите, увидите. Мы им пользуемся именно с 10-ю лицензиями. Внутри нашего отдела. Проблема что сразу начинает хотеться больше пользователей. Доступ разграничивать. А на 50 уже дорого.

А чем фигова просто "файловая версия"?

Ей вполне можно пользоваться. Я сталкивался с проблемами с параллельным доступом и иногда появляются ашипки если файлы на виндусевской самбе, а клиент - линукс. Или мак. Потому что в 2017 году пользоваться файловой системой не различающей реестр может только микроштоф. Самба тормозит. После перехода не сервер первое время вопросы были, мол, я запушил а он ничё не делает. - В смысле не делает? - Ну, я кнопку нажал и всё. Раньше ждал несколько секунд.

Лучше уж доступ по ссх организовать.

Сервер дает дополнительные плюшки. От возможности браузить репо на сервере до разделения доступа к веткам. Поддержка code review с помощью pull request-ов. По емылу оповещает о новых коммитах, если надо. Автоматизация на сервере. Запушил коммит, сервер добавил тэг с временем, увеличил номер багфикса, если это интеграционная ветка оповестил интегратора и пнул CI сервер, чтобы он сборку начинал и те пе. У битбакета хорошая интеграция с jira. Бэкапы настраиваются. В общем без всего этого можно жить. Дополнительное удобство. Ну и я не знаю как поведет себя гит с "файловой версией" если с репо будет человек 15-20 работать. Одновременно что-то начнут пушить... Кто-то победит (кто первый встал, того и тапки), кто-то в конце операции ошибку схлопочет, мол, не могу поменять референс. Из личного опыта: с 5-ю разработчиками нормально и с файловой версией.

вот только что попробовал

$ git svn clone --stdlayout E:\SVN-repo\svn-repo-test E:\Git-Repos\svn-repo-test-git

Initialized empty Git repository in E:/Git-Repos/MPG200_CustomApps/EGit-Repossvn-repo-test-git/.git/

E: 'trunk' is not a complete URL and a separate URL is not specified

----

$ git svn clone E:\SVN-repo\svn-repo-test E:\Git-Repos\svn-repo-test-git

Bad URL passed to RA layer: Illegal repository URL 'E:SVN-reposvn-repo-test' at /mingw64/share/perl5/site_perl/Git/SVN.pm line 148.

PS: "файловые" репо не поддерживаютсяю Из сервера вроде работает, только у меня нет большого проекта для тест...

Перенёс домашний репо, но тоже полный бардак.

Я просто работал с отдельными проектами в одном репо, когда надо было брал нужный или добавлял. Теперь всё в куче. Как разделить?

Посмотрите, увидите.

За 10 я могу и сам купить. Только Ява отпугивает. Сколько не пробовал продуктов на Яве - не было ни одного нормального.

Но если что, то только в октябре что то получится попробовать...

Дома давно пробовал ентот, но для него 17 студия нужнаб остальные SSH не поддерживают

https://www.synology.com/en-us/knowledgebase/DSM/help/Git/...

Из гуев могу только посоветовать SourceTree. С ним у меня было меньше всего проблем.

Поддерживаю, хорошая вещь. Вот ее нам как раз давеча зарубили. Также порекомендую TortoiseGit - в прошлой жизни на нем работали.

Сколько не пробовал продуктов на Яве - не было ни одного нормального.

Видел суслика? А он есть (с)

IntelliJ IDEA видел когда-нить? После нее студия покажется ужасным кошмаром.

Конкретно атлассианский стек - очень хорош. Дело не в жабе, дело в тех, кто продукт делают.

> В общем без всего этого можно жить.

Кодить тоже можно в нотпаде, чо уж там.

Также порекомендую TortoiseGit

По сравнению с Git Extension довольно далеко

Хм, Вы ведь всего лишь неделю сам Git курите. Поэтому зря, ой зря так самоуверенно.

Дело не в жабе, дело в тех, кто продукт делают

Да это вроде и понятно. Но это у меня как бы "народная примета". Каждый раз надеешься на лучшее, но как вижу специфические окошки почти сразу обнаруживается нечно, что не позволяет пользовать продукт дальше.

Кодить тоже можно в нотпаде, чо уж там.

Нельзя. Не по феншую. Только vi, только хардкор. Хотя через пару недель в vim-е опять же все становится раз в 10 проще и быстрее чем в ноутпаде, засада :)

У клиента оракл на аих. Вима нет, есть только голый ви :( Пичаль.

Так жаба на клиенте - это не жаба на сервере, которая дефакто стандарт энтерпрайз систем. Ну и опять же - идеа :)

IntelliJ IDEA

Может и видел, но не упомню. Jetbrains уже и так давно польую

Сейчас глянул демо видео ничего необычного не заметил.

Поэтому зря, ой зря так самоуверенно.

Глянуло одно, глянул другоею Концепт то совершенно разный

Я просто работал с отдельными проектами в одном репо, когда надо было брал нужный или добавлял. Теперь всё в куче. Как разделить?

Я раньше все сваливал к кастрюлю и варил борщ. Хотелось мяса, достал кусок, хотелось капусты, выловил немножко :)

Разделить в смысле сделать чтобы каждый проект в своей репо был? Простой ответ - с историей никак. Сложный ответ.. С filter-branch и --subdirectory вроде можно. В реальной жизни не пробовал пока что.
Вроде бы тут достаточно понятно описано.

PS: "файловые" репо не поддерживаютсяю Из сервера вроде работает, только у меня нет большого проекта для тест...

Точно-точно? А если поRTFM-ить немного и написать не выньдуфскую дорожку а URI? Вроде file:////E:/SVN-repo/svn-repo-test ?

Идеа и студия - как мерседес и запорожец.

Great Wall тоже с виду прекрасен. Но это такое, кому изюм, кому курага.

Разделить в смысле сделать чтобы каждый проект в своей репо был?

Как точно не знаю, но это чисто для дома. Пользователь 1, бранчей, тэгов и релизов не было. Стоит сервер SVN под никсами, там одно репо и в нём все проекты.

Пока вижу два пути: 1 проект - 1 репо, 1 репо х бранчей.

Идеа и студия - как мерседес и запорожец

примеры из практики мона? Только студия у меня с решарпером, не имею представления как "голая" студия фунциклирует.

Пока вижу два пути: 1 проект - 1 репо, 1 репо х бранчей.

Не-не, каждый проект в отдельную ветку не надо. Не для того они придуманы.

Если пользователь (разработчик) один, то можно и все проекты в одной репо держать.

Тут дело в том, что когда проектов много то и разработчиков много. И постоянно валятся новые коммиты, ветки, мержаться в мастер и те пе. Слишком много изменений - начинаешь путаться. Плюс со временем репо растет и одно дело клонировать 100 мегов, а другое ждать пока скачаются 3-4-5 гигов. Для меня есть еще один важный плюс: разделение проектов по разным репозиториям заставляет разработчиков думать над интерфейсами а не свинячить лишь бы побыстрее.

Коллега, а можете прояснить именно в части трехстороннего слияния? Каким образом оно работает с тремя коммитами, какой берется за основу, почему именно он и какой вклад остальных в результирующий?

Чтобы не писать много, давайте так: в викпедии описание 3-way merge достаточно простое и понятное. Вопрос как git находит наилучшего общего предка описан в документации git merge-base.

Если что не понятно будет - спрашивайте, если знаю - поясню.

Спасибо! Покурю завтра на работе.

Кстати, для любителей rebase очень рекомендую rerere.

Репозиторий распилить на пачку отдельных проектов с помощью git filter-branch: https://manishearth.github.io/blog/2017/03/05/understandin...

с какой версии СВН? Стараемся без нужды не обновлять, а то иногда получаются "приятные сюрпризы".

Посмотрел, наконец, версию SVN сервера нашего: Apache Subversion version 1.7.8