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

StackOverflow https://stackoverflow.com/questions/1880405

  •  18-09-2019
  •  | 
  •  

Вопрос

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

Всякий раз, когда в этих статьях признается, что вы не можете делать все, что делали бы в чистом 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?Есть ли какой - нибудь более простой способ сделать это?

Это было полезно?

Решение

Проблема, конечно, в шаге 4.dcommit пытается воспроизвести вашу локальную историю на сервере.Dcommit притворяется, что вы клиент SVN.Теперь, если код, который вы dcommitting, принадлежит не только вам, это то, что сложно dcommitting для 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, любые ветви git, в которые мы git нажимаем перед git svn dcommit на них, потребуют принудительной перезаписи существующей ссылки в удаленном репозитории .Обычно это считается плохой практикой, подробности см. В документации 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 или конфигурацией.Итак, репозитории, созданные и управляемые с помощью использование git-svn должно использовать rsync для клонирования, если клонирование вообще должно быть выполнено .
  • Мы не должны использовать опцию --amend в git commit для изменения, которое мы уже зафиксировали. Считается плохой практикой --изменять коммиты, которые мы уже отправили в удаленный репозиторий для других пользователей, и dcommit с SVN аналогичен этому.Более подробную информацию об этом можно найти в разделе Изменение одного коммита и Проблемы с переписыванием истории.

Другие советы

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

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

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

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

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

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

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

Как только вы приступите к «распределенной» проблеме, вам будет лучше иметь один голый репозиторий git, клонированный среди разработчиков.
Что касается этапа экспорта-импорта в общедоступный репозиторий SVN, для использования другими сценариями
git2svn и svn2git может помочь инкапсулировать магию.

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

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

СубГит — это двунаправленное серверное зеркало 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 устанавливает хуки предварительной фиксации и постфиксации в репозиторий Subversion, а хуки предварительного и пост-приема — в репозиторий 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.

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

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top