Могут ли разные клоны git-svn одного и того же хранилища svn иметь возможность делиться изменениями, а затем git svn dcommit?

Question

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

Всякий раз, когда в этих статьях признается, что вы не можете делать все, что делаете в чистом виде, последствия и возможные ошибки никогда не объясняются четко (или, может быть, это только я?). Даже в справочной странице git-svn упоминаются предостережения, но не очень широко.

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

Вот "требуемый" способ делать вещи:

1. У нас есть проект в хранилище SVN
2. Разработчик Git-svn-clone - это репозиторий SVN. Он начинает взламывать вещи локально
3. Разработчик B git-svn-clone - это тот же репозиторий SVN. Он начинает взламывать вещи самостоятельно.
4. После этого в течение некоторого времени, возможно, добавления разработчиков C/D/... и привлечения других разработчиков, которые выполняют "стандартные" SVN-коммиты к исходному репо, пользователи git хотели бы поделиться своим кодом и выполнить все виды магии git.,
5. Любой из этих пользователей git хотел бы иметь возможность перенести объединенные изменения в svn (dcommit?)

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

Иногда я читал, что это можно сделать, используя, по крайней мере, "официальный" голый репозиторий git, который будет единственным, который должен быть клонирован git-svn, и все пользователи git должны будут начать с этого. Затем вам нужен кто-то, кто отвечает за это центральное git-репо и собирает изменения между git-разработчиками, прежде чем отправлять все в svn-репо. Это был бы единственный способ для пользователей git "не знать", что исходный репозиторий git исходит от svn, и позволить им использовать все команды git по своему усмотрению. Единственным человеком, который должен был бы свободно говорить как в git, так и в svn (и знать о предостережениях git-svn), был бы "менеджер слияния" (или как там его называют).

Я полностью неправильно понимаю предостережения git-svn? Есть ли более простой способ сделать это?

Answer 1

Проблема в шаге 4, конечно. Dcommit пытается воспроизвести вашу локальную историю на сервере. Dcommit делает вид, что вы клиент SVN. Теперь, если код, который вы вводите, не только от вас, это то, что трудно передать в SVN.

Вот что гуру пишет по этому вопросу:

• Для простоты и взаимодействия с SVN рекомендуется, чтобы все пользователи git-svn клонировали, извлекали и dcommit напрямую с сервера SVN (который является удаленным SVN-репозиторием) и избегали всех git-clone / pull / merge / push операции между git-репозиториями и ветвями, которые либо извлекаются с помощью git svn clone и которые также используются для возврата наборов изменений в удаленный SVN-репозиторий.
• Рекомендуемый метод обмена кодом между ветвями git и пользователями - это git format-patch и git am или просто git svn dcommit в репозиторий SVN.
• Поскольку git svn dcommit внутренне использует git svn rebase, любые ветки git, которые мы нажимаем перед git svn dcommit, требуют принудительной перезаписи существующего ref в удаленном репозитории. Обычно это считается плохой практикой, подробности смотрите в документации git-push.
• Запуск git merge или git pull не рекомендуется для ветки, из которой мы планируем выполнить git svn dcommit. SVN не представляет слияния каким-либо разумным или полезным способом, поэтому пользователи, использующие SVN, не могут видеть слияния, которые мы сделали. Более того, если мы выполняем git merge или git pull из ветви git, которая является зеркалом ветви SVN, git svn dcommit может зафиксировать неверную ветку.
• git clone не клонирует ветви в иерархии refs/remotes/, а также в любых метаданных git-svn или config. Таким образом, репозитории, созданные и управляемые с использованием git-svn, должны использовать rsync для клонирования, если клонирование вообще необходимо сделать.
• Мы не должны использовать параметр --amend git commit для изменения, которое мы уже внесли. Считать плохой практикой --amend коммиты, которые мы уже отправили в удаленный репозиторий для других пользователей, и dcommit с SVN аналогичен этому. Дополнительную информацию об этом можно найти в разделе "Изменение одного коммита" и " Проблемы с переписыванием истории".

Answer 2

В последнее время я много экспериментировал с этим и думаю, что мне удалось придумать установку, которая несколько работает. Да, это строгий режим только для перебазирования, да, он сложный, но вы можете использовать Git для локальной работы (скорость, история, тайник, индекс и т. Д.).

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

Вот короткая версия (много повторяет то, что уже было сказано):

1. Клонировать репозиторий Subversion в "извлекающий" репо на центральном сервере
2. Инициировать "голое" репо на том же сервере
3. Толчок от бесподобного репо к голому репо
4. Пусть разработчики клонируют голое репо, а затем
   5. git svn init svnurl настроить удаленный git-svn и
   6. git update-ref refs/remotes/git-svn refs/remotes/origin/master так что git-svn имеет указатель на ревизию
5. Автоматически (коммит хук) имеет "выборочный" репозиторий svn rebase и подталкивает к голому репо
6. Разработчики вытягивают из голого репо с git pull --rebase
7. Разработчики работают git svn dcommit сначала нужно повторить update-ref выше в случае более новых версий, поступающих из SVN.

На этой странице есть иллюстрация рабочего процесса (мне нужно больше очков репутации, прежде чем я смогу вставить изображение). Обновление: здесь мы идем:

Answer 3

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

Казалось, что он работал правильно, поскольку мы могли использовать "определенные функции git" между пользователями git, пока мы оставались в линейном дереве (то есть перебазировали вместо слияния).

Answer 4

Существует инструмент, который решает проблему совместного использования Git-репозитория, синхронизированного с Subversion-репозиторием.

SubGit является двунаправленным зеркалом на стороне сервера Git-SVN.

Можно установить SubGit в репозиторий Subversion и автоматически синхронизировать Git-репозиторий с SVN:

$ subgit configure $SVN_REPOS
# Adjust $SVN_REPOS/conf/subgit.conf to specify branches, tags and other options;
# Adjust $SVN_REPOS/conf/authors.txt to specify git & svn authors mapping
$ subgit install $SVN_REPOS
...
$ INSTALLATION SUCCESSFUL

SubGit устанавливает хуки pre-commit и post-commit в репозиторий Subversion, хуки pre-receive и post-receive в репозиторий Git. В результате он немедленно переводит входящие модификации со сторон SVN и Git. После установки SubGit разработчики могут использовать любой клиент Git для клонирования и работы с репозиторием Git.

SubGit не полагается на git-svn, он использует собственный механизм перевода, разработанный нашей командой. Более подробную информацию об этом вы можете найти в сравнении SubGit и git-svn. Общая документация по SubGit доступна здесь.

Версия 1.0 SubGit требует локального доступа к хранилищу Subversion, то есть хранилища SVN и Git должны находиться на одном хосте. Но с версией 2.0 мы собираемся ввести режим прокси Git, когда репозитории Subversion и Git могут быть расположены где угодно, и только репозитории Git имеют установленный SubGit, то есть репозитории Subversion остаются нетронутыми.

SubGit является коммерческим продуктом. Это бесплатно для открытого проекта, академического проекта, а также для проектов с до 10 коммиттеров.

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

Answer 5

Как только вы вступаете в "распределенную" проблему, вам лучше с одним голым репозиторием, клонированным среди разработчиков.
Относительно фазы экспорта-импорта в общедоступном репозитории SVN, для использования другими сценариями
git2svn и svn2git могут помочь инкапсулировать магию.

Другие соображения при работе с репозиториями Git и SVN можно найти в вопросе "Рабочий процесс и помощь с git, 2 проекта svn и одна" рабочая копия "".

Answer 6

Я нашел этот пост в блоге, в котором предлагается сохранить отдельную ветку для синхронизации с репозиторием Subversion, чтобы в основной ветке все еще можно было делать push/pull.

Answer 7

Одна из проблем, с которыми я сталкиваюсь при использовании git-svn, заключается в том, что он сохраняет git-svn-id в комментарии к коммиту; потому что это переписывает этот коммит, он меняет его на SHA1, так что вы не сможете отправить его туда, где люди будут делиться им.

Я на самом деле предпочитаю bzr-svn, потому что вместо этого он сохраняет bzr revid в удаленной ревизии SVN, используя вместо этого функцию свойств ревизии SVN, что означает отсутствие перезаписи локальной ревизии. Он также обладает желаемым свойством, что два независимых извлечения одной и той же ветви SVN приведут к идентичным и совместимым ветвям bzr.