Что такое за и против использования мерзавца-svn?

Это конкретные за и против использования git-svn. Так что дело не в самом git.

Pro :

Люди, использующие svn, обычно фиксируют большие изменения сразу, потому что вам нужно выполнять фиксацию по сети. Такой подход может быть плохим, потому что иногда изменения могут не быть связаны друг с другом. например: вы можете иметь изменения с исправлениями и изменения для новой функции, зафиксированные в одном наборе изменений. С помощью git я могу фиксировать изменения в моем локальном репозитории git (особенно, когда я не подключен к сети) и иметь как можно меньший набор изменений. Затем я передаю svn (используя 'git svn dcommit'), когда все большие изменения готовы.

Con :

Недостаток svn в качестве удаленного репозитория объединяется, особенно когда есть конфликты. Иногда это может быть болезненно. Я использую IntelliJ в качестве своей IDE, и для разрешения конфликтов мне нужно перейти в командную строку, чтобы исправить это. Зная, что я часто сталкиваюсь с этой проблемой, я задокументировал ее , и теперь это больше не имеет для меня большого значения.

Я перешел на git с помощью git-svn. Наш репозиторий svn по-прежнему в рабочем состоянии, и мы по-прежнему получаем все "git awesomeness". По сути, после клона git-svn вы снова разветвляете его как свой «ствол». Отсюда все, кто использует git, ответят. Когда вам нужно получать обновления из svn, вы просто выполняете git-svn rebase, а затем git merge --squash из ветки svn в новый «ствол». И наоборот. Это будет означать, что ваша история в репозитории svn не будет соответствовать тому, что указано в git. Когда вы выполняете более одного слияния, в какой-то момент вам придется начать прививать коммиты, потому что история не совпадает. Однако, если вы привяжете ГОЛОВУ своего ствола git к последнему идентификатору фиксации, который был сжатым слиянием, вы получите тот же эффект.

Хорошо, позвольте мне разобрать это как можно лучше на примере.

svn repo: svn: //xyz.com/myproject

git svn clone svn://xyz.com/myproject

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

git checkout -b git_trunk

git_trunk становится "стволом" для пользователей git .

Эту ветвь можно свободно использовать, как и любой другой репозиторий git.

Теперь вам нужно синхронизировать эти две ветки с помощью git merge --squash

Например .. слияние из основной ветки svn в git_trunk

git checkout git_trunk
git merge --squash master
git commit -a 

Вы бы сделали то же самое, чтобы выполнить слияние из git_trunk с главным svn за исключением того, что вы выполнили бы

git svn dcommit

. Это вернет его обратно в svn.

Таким образом, сложность в том, что, поскольку мы используем --squash, история слияния теряется, и единственный общий предок, о котором git когда-либо узнает, - это ветка точка. Это будет означать конфликты слияния. Я решил это, выполнив что-то вроде этого

Слияние из git_trunk в master. Сначала я беру идентификатор последнего сквоша на git_trunk. Назовем это ABCDEFG. Затем я получаю фиксацию git_trunk. Допустим, это HIJKLMNO

echo "HIJKLMNO ABCDEFG" > .git/info/grafts

Это сообщит git при слиянии, что наиболее распространенным предком является последний сжатый коммит.

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

Мой опыт работы с git-svn показывает, что он в первую очередь полезен (опытным) пользователям git, которые хотят иметь похожий на git интерфейс для репозитория Subversion. Усвоение набора концепций git и ограничений git-svn было слишком большим, по крайней мере для меня.

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

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

Я думаю, что изменение git не решит ваших проблем. Если у вас есть «непрограммисты» внутри вашей рабочей силы, и они сломают рабочую копию других людей (я предполагаю, переименовав / удалив каталоги или файлы).

Если вы будете использовать git-svn или git или что-то еще, VCS и людей по-прежнему переименовывать / удалять свои каталоги, как это может стать лучше?

Я думаю, вам следует попытаться научить некоторых людей понимать основные концепции VCS.

Если люди не понимают рабочих процессов SVN, я сомневаюсь они освоят git-svn или git.

Я не вижу проблем, чтобы перенести весь репозиторий svn на git, сохранив в нем историю и все остальное, а затем полностью переключиться на git.

2 ГБ - это слишком много для одного репозитория. Может, стоит разбить его на несколько частей?

Том Престон-Вернер, Крис Ванстрат и Скотт Чакон —Git, GitHub и социальное кодирование: http://developer.yahoo.com/yui/theater/video.php?v=prestonwerner-github

Если используется:

• «Мы сохраняем SVN, но у нас есть Git для быстрого внутреннего ветвления», не нужно использовать git-svn : вы можете ' git init ' непосредственно в ветке вашей рабочей области Subversion, а git hack прямо в этой части вашего кода.

Но если это:

• «Мы поддерживаем и центральное репозиторий SVN, и репозиторий Git», тогда все немного сложнее , потому как:
  • простой git-svn будет воспроизводить «ветки SVN» (на самом деле простой каталог с копиями в нем), поэтому я бы рекомендовал использовать svn2git и git2svn
  • попытка импортировать все в один репозиторий Git не всегда является хорошей идеей (см. « Каковы ограничения git? »): если ваша система состоит из разных модулей, которые могут быть разработанные независимо друг от друга, они могут находиться в одном центральном репозитории SVN, но у них должно быть собственное репозиторий Git (чтобы иметь возможность извлекать только те модули, которые вам нужны)