GIT слияние веток SVN не может создать файл BASE - PullRequest
0 голосов
/ 08 августа 2011

Я работаю над проектом, который использует SVN для CVS, и около 5-6 месяцев назад мы разветвляли ветку version_1_9_1 из транка. Теперь я должен объединить их.

Чтобы облегчить мою работу с svn, я хотел попробовать git для слияния, поэтому я следовал инструкциям по адресу: http://blog.wuwon.id.au/2010/09/painless-merge-conflict-resolution-in.html

В итоге я использую следующие команды:

git svn clone -s hxxp://svn/repo/project project (this takes avout 20min for +30k commmits)
git checkout -b version_1.9.1 remotes/version_1_9_1
git checkout -b the_trunk trunk
git merge version_1.9.1

но когда я делаю 'git mergetool' для, скажем, файла web.xml, meld открывает диалоги для LOCAL и REMOTE, но BASE-файл отсутствует.

Пока диалоги слияния все еще открыты, проверьте, какие есть файлы, и получите следующий список:

web.xml
web.xml.BACKUP.12480.xml
web.xml.LOCAL.12480.xml
web.xml.REMOTE.12480.xml

Итак, для моего понимания должен быть также файл с именем web.xml.BASE.12480.xml, но его нет.

Результат один и тот же, независимо от того, включен или отключен diff3.

Это привело меня к мысли, что с клонированием что-то не так ... Поэтому я выполнил следующие команды в чистой директории:

git svn clone -s hxxp://svn/repo/project project
gitk
git checkout -b version_1.9.1 remotes/version_1_9_1
gitk
git checkout -b the_trunk trunk
gitk

(Кстати. Я делаю это в Ubuntu 11.04)

Каждый раз, когда я запускаю gitk, я вижу плоскую «иерархию», где все svn коммиты следуют за другим. Так что, если я правильно понимаю, что-то не так с «git svn clone», так как git не может найти общего предка для trunk и branch version_1.9.1.

Может кто-нибудь указать мне правильное направление в этом вопросе?

Спасибо за чтение.

1 Ответ

0 голосов
/ 11 августа 2011

Проблема была с веткой svn. Он был раздвоен от ствола, чтобы между ними не было связи.

Чтобы проверить, что я использовал:

$ git svn clone -s hxxp://svn/repo/project project
$ git checkout -b the_trunk remotes/trunk
$ git checkout -b version_1.9.1 remotes/version_1_9_1
$ git branch
   master
   the_trunk
   version_1.9.1
$ git merge-base the_trunk version_1.9.1

merge-base ничего не печатал, что говорит о том, что эти две ветви не имели отношения.

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

  1. Я искал последний коммит в транке, откуда была разветвлена ​​версия_1_9_1.
  2. создал новую ветку git с этой точки
  3. заменил весь контент из этой новой ветки на содержимое version_1_9_1
  4. слил его в багажник
  5. весело проводил время с конфликтами слияния (серьезно, это было намного проще, чем предлагал svn).

Ниже приведены команды для выполнения 5 шагов выше:

$ gitk <= to find git revision id of forked commit, lets say its 97bc8071-70e0-0310-82d1-dfb2d704a1b1
$ git checkout the_trunk
$ git branch fake_version_1.9.1 97bc8071-70e0-0310-82d1-dfb2d704a1b1
$ git checkout version_1.9.1
$ mkdir ../temp
$ cp -r projectfiles ../temp     <= remember not to copy .git directory
$ git checkout fake_version_1.9.1
$ rm -r projectfiles
$ cp -r ../temp/* .
$ git commit -a
$ git checkout the_trunk
$ git merge fake_version_1.9.1
$ git mergetool     <= google "git mergetool" for instruction to setup tool for conflicts, I used p4merge
$ git commit -a
$ git svn dcommit

В целом, я был очень счастлив с этим слиянием. Потребовалось некоторое время, чтобы выяснить, что эти две ветви не были связаны друг с другом, что не позволило git merge создать файл .BASE. Создание поддельной ветки позволило git создать файл .BASE, что значительно упростило слияние: Всего изменено файлов: 390 файлов

Конфликты слияния без поддельной ветки: 220 файлов против Конфликты при слиянии с поддельной веткой: 68 файлов

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

Спасибо за чтение.

...