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