git svn gatekeeper репозиторий

Question

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

Джон Лоулигер "Контроль версий с помощью Git".Я купил его, и это действительно хорошо, но я не совсем понимаю руководство по настройке репозитория git svn gatekeeper.

В главе 16 он описывает ситуацию, в которой существует хранилище Subversionи, по крайней мере, пару пользователей, которые хотят использовать Git.Он предлагает единственный git-репозиторий «привратник», который является единственным интерфейсом к Subversion.После клонирования git svn репозитория subversion (с --prefix = svn /) все ветви затем помещаются в пустой репозиторий (git push ../svn-bare.git 'refs / remotes / svn / : refs/heads / svn / ', и другим пользователям git говорят клонировать этот репозиторий, который теперь содержит локальные ветви всех удаленных svn.

Эта часть работает, и я думаю, что я полностью понимаюно я не получаю следующую часть:

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

В книге написано

Затем объединитьВернувшись к Subversion, в репозитории привратника вы делаете

git checkout svn / trunk (или другую ветку - это проверка отсоединенной головы, так как svn / trunk удаленный) git merge --no-ff newgit svn dcommit

Hoя могу оформить ветку в пустом хранилище?Я не думаю, что это работает

Это приводит к фиксации слияния на отдельной голове, а затем измененный коммит (после добавления строки git-svn-id) помещается в реальный svn/ ствол ветка.

Что подразумевается под реальным svn / trunk?

Фиксация на отсоединенной голове "хуже избыточной. Использование ее для чего-либо еще в конечном итоге приводит к конфликтам. Так чтопросто забудь об этом коммите. Если ты вообще не положил его на ветку, его гораздо легче забыть "(Джон Лоулигер).

Я немного растерялся.Есть ли у кого-нибудь лучшее объяснение для создания репозитория git svn gatekeeper?Я искал в Интернете и на этом сайте, но не нашел ничего подходящего для меня.

Я так устал тратить столько времени на ветвление и слияние svn, работая с моими коллегами.

Answer 1

Как оформить ветку в голом репозитории?Я не думаю, что это работает

Да, это так: вы просто клонируете голое репо локально, делая не голое репо в процессе, где вы можете оформить заказ / создать(опять же локально ) столько веток, сколько вы хотите.

Требуется голое репо в качестве восходящего репо, куда нужно нажать.(см. «git push только для открытых репозиториев? »)

Но для того, чтобы что-то подтолкнуть к этому, т. е. чтобы другие разработчики отправили свои изменения в ветки не-svn обратно врепозиторий-привратник сказал, что другой разработчик должен сначала клонировать этот голый репозиторий, внести все соответствующие изменения в локальную копию и вернуться обратно к голому репо.
Плюс, вы можете настроить некоторые хуки на этом голом репо, чтобыпроверьте ваш толчок: см. « Хуки для git-svn ».

Затем, чтобы dcommit, привратник также клонировал репо привратника, из которого он / она будет:

• извлечение удаленной ветви, связанной с svn ('svn' - это имя удаленного репо), например, svn/trunk, например
• , объединить соответствующее изменение в этой неназванной ветви
• git-svn dcommit

Итак, резюмируем:

• клон разработчика, репозиторий привратника, чтобы записать свои изменения в своей собственной ветви (которую они могут отодвинуть назад, поскольку привратник репо является голым)
• peОтветственный за возвращение к настоящему репозиторию SVN также клонирует этот репозиторий привратника, чтобы выбрать, что необходимо объединить с веткой Git, специально привязанной к SVN (см., например, " Overcome git svn caveats ").

Answer 2

Я попытался автоматизировать настройку гейткипера , описанную Джоном Лоулигером, и получил его в работу.Он начинает очень подробно о том, какие шаги нужно выполнить, но часть «Объединение в Subversion» довольно коротка.Я пробовал разные настройки с помощью git-svn, также следовал отличным презентациям / примерам , данным Томасом Феррисом Николаизеном, и использовал его примеры проектов (с модификациями) для тестирования «настройки привратника»:

@echo 1. Clone Subversion repo
cd %WDIR%\devs\adm
call git svn clone -s --prefix=svn/ http://localhost/svn-repos/company-repo/websites --    username adm
cd %WDIR%\devs\adm\websites
call git reset --hard svn/trunk

@echo ----------------------------------
@echo  2. Create bare repo
cd %WDIR%\devs\adm
mkdir websites.git
cd websites.git
call git init --bare 

@echo ----------------------------------
@echo  3. Populate bare with content from gatekeeper 
cd %WDIR%\devs\adm\websites
call git push --all ../websites.git
call git push ../websites.git "refs/remotes/svn/*:refs/heads/svn/*"

@echo ----------------------------------
@echo  4. Setup bare as a remote in gatekeeper and fetch branches 
call git remote add bare_repo ../websites.git
call git fetch bare_repo

Шаг 4 не описан Джоном Лоилигером, но я думаю, что именно это он и сделал.

Когда пришло время объединиться с Subversion, выполните:

C:\tmp\devs\adm\websites>git fetch bare_repo
remote: Counting objects: 6, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 4 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (4/4), done.
From ../websites
   e53fba9..2ac281c  svn/trunk  -> bare_repo/svn/trunk

Теперь мы можем выполнить шаги из книги:

C:\tmp\devs\adm\websites>git checkout svn/trunk
Note: checking out 'svn/trunk'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b new_branch_name

HEAD is now at e53fba9... [maven-release-plugin] prepare release kaksi

C:\tmp\devs\adm\websites>git merge --no-ff remotes/bare_repo/svn/trunk
Merge made by the 'recursive' strategy.
 0 files changed
 create mode 100644 web/howto.txt
 create mode 100644 web/readme.txt

C:\tmp\devs\adm\websites>git svn dcommit
Committing to http://localhost/svn-repos/company-repo/websites/trunk ...
        A       web/howto.txt
        A       web/readme.txt
Committed r8
        A       web/readme.txt
        A       web/howto.txt
r8 = 28da267255ae56022bd4ed3c0f4886da1ac04944 (refs/remotes/svn/trunk)
No changes between current HEAD and refs/remotes/svn/trunk
Resetting to the latest refs/remotes/svn/trunk

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

C:\tmp\devs\adm\svn\websites>svn log
------------------------------------------------------------------------
r8 | adm | 2012-05-12 23:21:11 +0200 (lø, 12 mai 2012) | 1 line

Merge remote-tracking branch 'remotes/bare_repo/svn/trunk' into HEAD
------------------------------------------------------------------------

Теперь рассмотрим эту альтернативу для слияния обратно в подрывную деятельность:

C:\tmp\devs\adm\websites>git checkout -t svn/trunk
Branch trunk set up to track local ref refs/remotes/svn/trunk.
Switched to a new branch 'trunk'

C:\tmp\devs\adm\websites>git fetch bare_repo
remote: Counting objects: 6, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 4 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (4/4), done.
From ../websites
   c188a72..b1b4237  svn/trunk  -> bare_repo/svn/trunk

C:\tmp\devs\adm\websites>git rebase remotes/bare_repo/svn/trunk
First, rewinding head to replay your work on top of it...
Fast-forwarded trunk to remotes/bare_repo/svn/trunk.

C:\tmp\devs\adm\websites>git svn reset 2147483647
r7 = c188a72da6df2966e563e9e575b626d5b449400f (refs/remotes/svn/trunk)

C:\tmp\devs\adm\websites>git svn rebase
Current branch trunk is up to date.

C:\tmp\devs\adm\websites>git svn dcommit
Committing to http://localhost/svn-repos/company-repo/websites/trunk ...
        A       web/howto.txt
        A       web/readme.txt
Committed r8
        A       web/readme.txt
        A       web/howto.txt
r8 = 18b7c7b4693cc8e55098bd716c9259ed5570acf0 (refs/remotes/svn/trunk)
No changes between current HEAD and refs/remotes/svn/trunk
Resetting to the latest refs/remotes/svn/trunk

Теперь история коммитовне поврежден:

C:\tmp\devs\adm\svn\websites>svn log
------------------------------------------------------------------------
r8 | adm | 2012-05-12 23:51:48 +0200 (lø, 12 mai 2012) | 1 line

'ola added [readme.txt, howto.txt] on svn/trunk'

Чтобы эта настройка работала, нам нужно использовать команду 'git svn reset', иначе dcommit завершится с ошибкой во второй раз, потому что git-svn запутан в текущемревизия и находится позади (до той же ревизии, что и при создании голого репо).Вероятно, это связано с тем, что мы использовали rebase, что, в свою очередь, необходимо для получения хорошей линейной истории в Subversion.

Большой вопрос: что на самом деле делает «git svn reset»?
Является ли «сброс вперед» законным использованием «git svn reset» в этом случае?

Answer 3

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

http://blog.tfnico.com/2010/10/gitsvn-5-centralized-git-svn-mirror.html

В моей настройке (которую я использую в течение 3-4 месяцев без проблем) изменения всегда должны «протекать» через репозиторий SVN. Я не очень понимаю эту технику привратника ..