После "git svn clone" у меня все еще нет фантастического коммита слияния веток? - PullRequest
2 голосов
/ 24 ноября 2011

После того, как я сделал git svn clone --stdlayout ... , все выглядит хорошо, и я преобразовал удаленные ветви.Но когда git log --graph , я не вижу ни одного графа слияния ветвей.Это нормально?

Ответы [ 3 ]

5 голосов
/ 02 декабря 2011

Начиная с версии 1.5.0, выпущенной летом 2008 года, Subversion поддерживает отслеживание слияний. Subversion хранит информацию о выполненных слияниях как svn: mergeinfo свойство, установленное для цели слияния, будь то каталог филиала, такой как ^ / trunk / , или любой другой каталог.

Существуют значительные различия между механизмами отслеживания слияний в Git и Subversion:

  1. Вся ветвь сливается.

    Когда вы находитесь на master ответвлении, команда

    $ git merge some-branch
    

    приводит к коммиту слияния с его первым родителем, установленным на коммит, на который ссылается master , и вторым родителем, установленным на коммит, на который ссылается some-branch (я не беру перемотка вперед и конфликтующие слияния здесь).

    Для git это означает, что созданный коммит слияния включает всю историю обоих master и some-branch .

    Когда вы извлечете ^ / trunk / , перейдите в рабочую копию svn и запустите

    $ svn merge ^/branches/some-branch trunk-working-copy
    

    Subversion установит свойство svn: mergeinfo в каталоге с работающими копиями:

    /branches/some-branch:10-20,30-40,50-60
    

    Диапазон 10-20,30-40,50-60 включает в себя те ревизии, которые еще не объединены в ^ / trunk / ветвь из ^ / branch / some-branch / (Subversion обнаруживает их автоматически).

    Свойство Mergeinfo просто указывает те ревизии, которые когда-то были объединены в ветку. И пользователь должен проверить, включают ли все эти объединенные ревизии всю историю ветви.

  2. Вишневое слияние.

    Когда вам нужно объединить изменения из одного коммита в ветку master , вы запускаете

    $ git cherry-pick bc347a8
    

    После этого git создает коммит с соответствующими изменениями, а один родительский элемент устанавливает коммит, на который ранее ссылалась ветка master .

    То есть git не создает никаких коммитов слияния для cherry-pick. Таким образом, у git нет средств для отслеживания вишневых коммитов через структуру графа.

    В противоположность этому Subversion отслеживает слияние вишенок, настраивая свойство svn: mergeinfo относительно выбранной вишнёвки:

    $ svn merge -c100 ^/branches/some-branch trunk-working-copy
    

    Эта команда довольно проста, она настраивает svn: mergeinfo следующим образом:

    /branches/some-branch:100
    

    Это означает, что Subversion отслеживает слияние вишенков

Итак, вы не получаете коммитов слияния после перевода. Насколько я знаю, у git-svn есть определенные проблемы, когда дело доходит до истории слияния.

Но как разработчик subgit я должен сказать, что subgit должен правильно обрабатывать информацию отслеживания слияний. Скорее всего, свойство svn: mergeinfo , установленное в ваших ветках, не включает всю историю слитых в них веток. Вот как это может произойти:

  • Вы использовали старый svn-клиент (<1.5), поэтому в ваших филиалах недостаточно информации для отслеживания слияний. </li>
  • Вы выполнили вишневый отбор и пропустили некоторые диапазоны ревизий, начиная с добавления в svn: mergeinfo .
  • У вас есть svn: mergeinfo , установленный для каталогов, которые не являются каталогами филиалов, т.е. они не ^ / trunk / , ^ / branch / some-branch и т. д. (для стандартной компоновки).

Чтобы исправить это, вам нужно найти пропущенную часть информации об отслеживании слияний и добавить ее в свои ветки:

  1. Попробуйте найти, какая ревизия еще не объединена:

    $ svn mergeinfo --show-revs eligible ^/branches/some-branch/@HEAD ^/trunk/@HEAD
    

    Выходные данные должны включать все ревизии, которые вы еще не объединили, от ^ / branch / some-branch / до ^ / trunk / .

  2. Попробуйте объединить еще не объединенные ревизии по svn.

    • Если вы считаете, что все изменения уже объединены, используйте параметр --record-only команды svn merge;
    • Если вы не уверены, лучше выполнить обычное svn-слияние, в котором будут применены все пропущенные изменения.
  3. Используя subgit, вы также можете выполнять слияние средствами git, а затем отправлять созданные коммиты слияния в репозиторий с поддержкой subgit, поэтому он преобразует эти коммиты слияния в svn-ревизии с правильным svn: mergeinfo.

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

1 голос
/ 25 ноября 2011

Subversion отслеживает слияние с помощью свойства svn: mergeinfo. Хотя история может не отображаться в виде графика вашим инструментом, она не является линейной по своей природе. На самом деле svn: mergeinfo более мощный, чем коммиты Git merge (хотя эта возможность может быть бесполезна)

Такие инструменты, как SubGit переводит svn: mergeinfo в коммиты слияния, когда это возможно.

Я работаю над инструментом, который я рекомендовал (SubGit), но на самом деле git-svn очень слаб в переводе слияний в обоих направлениях.

0 голосов
/ 24 ноября 2011

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

...