Каковы плюсы и минусы использования git-svn? - PullRequest
6 голосов
/ 21 августа 2009

Я устал от Subversion, он продолжает портить свой собственный репозиторий. Поскольку я долгое время любил git и всегда хотел попробовать его, я решил попробовать и использовать git-svn. Но, прочитав документацию, я понял, что вы не можете использовать большую часть мерзавца с ним. Вы не можете использовать git-pull, не рекомендуется создавать локальные ветки и существует множество ограничений. Похоже, это не намного лучше, чем использовать Subversion напрямую. Либо это? Какие плюсы и минусы у git-svn по сравнению с простым svn?

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

Ответы [ 8 ]

4 голосов
/ 21 августа 2009

Плюсы:

  • Всё, для чего Git хорош:
    • Сетевой доступ ко всем старым коммитам
    • Коммит и ребаз в Git (опять же, без сети), а затем git svn dcommit, чтобы отправить все изменения в SVN для хорошей чистой фиксации
    • Дешевое локальное ветвление (не знаю, почему вы говорите, что это не так хорошо работает)
  • Не нужно так много общаться с SVN :)

Минусы:

  • Намного лучший рабочий процесс, если вы уже знаете и Git, и SVN (т.е. не очень хорошо для новых пользователей системы контроля версий)
  • Смущает всех остальных, если они смотрят на то, что вы делаете
  • Некоторые функции SVN (такие как svn: ключевые слова) недоступны / удобно
3 голосов
/ 23 августа 2009

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

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

svn репо: 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 и master svn. кроме как выполнить

git svn dcommit

Это вернет его к SVN.

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

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

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

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

Это не идеально, но прекрасно работает для меня. Особенно сейчас, так как почти все на Git.

3 голосов
/ 22 августа 2009

Это специальные "за" и "против", использующие git-svn. Так что дело не в самом Git.

Pro

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

Con

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

2 голосов
/ 21 августа 2009

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

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

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

1 голос
/ 21 августа 2009

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

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

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

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

1 голос
/ 21 августа 2009

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

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

Но если это так:

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

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

0 голосов
/ 21 августа 2009

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

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

...