Какая часть мощности git теряется при использовании git-svn и общей магистрали subversion?

Question

Я оцениваю различные варианты отвлечения нашей команды от CVS. У нас есть другая большая команда на другом сайте, использующая Subversion, и некоторые наши разработчики работают с сервером Subversion. Поэтому Subversion - очевидный выбор для нашей команды. Тем не менее:

1. Операции, связанные с Subversion сервер может быть медленным перерывом на кофе (хотя у нас хорошая связь между сайтами).
2. Многие из нас наши продали по идее распределенной версии контролировать и использовать Mercurial или git (а затем объединить и зафиксировать CVS и получить изменения с

git-svn выглядит интересно но я хотел бы знать, сколько мощности DVCS, такой как git, теряется при наличии нескольких централизованных веток в Subversion. В частности, я все еще хотел бы иметь возможность сохранять рабочий процесс, который мы имеем с Mercurial, такой как:

1. Можем ли мы вытащить репозитории других членов команды и объединиться, и, таким образом, сотрудничать в функциональных ветвях, прежде чем они перейдут в наш основной стабильный ствол на Subversion?
2. Можем ли мы ожидать, что множество хитростей, которые возможны с git, будут работать вообще, или мы должны быть осторожны, чтобы не запутать git-svn?
3. Можем ли мы использовать git для ускорения извлечения из Subversion, потянув его через соединение с другого сайта один раз, а затем один раз потянув его в отдельные репозитории.
4. Если кто-то фиксирует Subversion, можем ли мы организовать, чтобы другие пользователи git через git-svn по-прежнему видели полную историю разработки?
5. Можем ли мы в основном избежать ожидания интерактивных операций на сервере Subversion, несмотря на то, что он имеет половину задержки?

Многие из нас привыкли к идее основной довольно стабильной разделяемой ветви с простой линейной историей, к которой каждый может подтолкнуть, и поэтому они регулярно сливаются в верхушку. Мне не ясно, как хорошо поддерживать этот рабочий поток с помощью git (или Mercurial, или Bazaar).

Answer 1

Вы много теряете, и это похоже на второй класс, но вы получаете все замечательные вещи ветвления.

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

В конце концов, мы завершили работу над проектом из-за всей информации, которая была потеряна при переходе в Subversion.

Что вы теряете:

1. Отслеживание слияния - вроде.
2. Правильная запись авторства изменений.

Я говорю "своего рода" WRT # 1, потому что если вы держите одно дерево вместе, оно будет отслеживать слияния и прочее, что вы сделали с git и применить к Subversion, но как только вы попытаетесь клонировать это репо или кого-то еще делает клон git-svn, вы теряете это, и слияния снова становятся действительно болезненными.

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

Answer 2

Как уже упоминалось, git-svn имеет определенные ограничения по сравнению с pure Git Experience:

1. Командное сотрудничество жесткое:

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

2. Потерянные метаданные:

   Файлы

   .gitignore и .gitattributes теряются, когда git-svn отправляет изменения в SVN, то есть git-svn не преобразует эти метаданные в соответствующие свойства Subversion. Другие разработчики не получают изменения метаданных при получении.

3. Потерянные данные отслеживания слияния:

   Если объединить две ветви с git и затем нажать кнопку подтверждения слияния с git-svn, хранилище Subversion не получит никаких данных об истории слияния автоматически.

4. Слабая поддержка ветвления:

   Нужно создать ветку в хранилище Subversion, получить ее с помощью git-svn и только затем dcommit внести изменения в эту ветку. Если создать обычную ветку Git и попытаться отправить ее обратно в репозиторий SVN, git-svn не создает новую ветку, а вместо этого отправляет коммиты в существующую.

SubGit является альтернативой git-svn со следующими функциями:

• SubGit работает на стороне сервера как набор хуков, он синхронизирует репозитории SVN и Git, сохраняя возможность записи обеих сторон;

• Можно использовать любой Git-клиент для работы с Git-репозиторием с поддержкой SubGit; поддерживается любой рабочий процесс Git;

• SubGit устраняет все перечисленные выше проблемы git-svn.

SubGit - коммерческое программное обеспечение со многими бесплатными опциями. За дополнительной информацией обращайтесь к документациям и сравнение с git-svn .

Отказ от ответственности: я один из разработчиков SubGit.

Answer 3

Для того, что я видел, вы можете использовать git между извлечением из репозитория с помощью git-svn (так что вы можете иметь публичный репозиторий git, который будет «зеркалом» репозитория svn, о котором вы говорите, но git репо может быть размещен на вашем сайте).

Таким образом оформление / клонирование / push / pull для пользователей git будет быстрым. Тогда я думаю, что вы можете добавить хуки к вашему git-репо для синхронизации с svn-репо через git-svn, но вам придется иметь дело с конфликтом, пока вы не используете разные ветви.

Что мы делаем здесь, так это то, что у каждого разработчика есть ветвь с его именем, и он должен слиться с веткой master (поэтому он обрабатывает конфликт), прежде чем администратор объединит свою ветку с мастером, без какого-либо конфликта, так как dev уже справиться.

Надеюсь, эта помощь.