2010-12-13 3 views
9

У меня возникла проблема слияния подмножества ревизий от одной ветви темы к другой. Поскольку я использую git-svn, мне было любопытно узнать, можно ли использовать вишневый сбор для этого. Используя Subversion, я бы сделал:cherry-picking with git-svn

svn merge -c A 
svn merge -c B 
svn merge -c C 
... 
svn commit ... 

Что произойдет, если я попытаюсь это сделать?

git checkout branch1 
git cherry-pick A 
git cherry-pick B 
git cherry-pick C 
git svn dcommit 

Если я прочитал мерзавец Svn человек-страницу, ответы есть «не делай этого», но я получаю впечатление, когда прибегая к помощи вокруг этого мерзавца СВН делает работу намного лучше теперь с этими видами вопросов ,

ответ

8

Когда вы сделаете git svn dcommit, он будет последовательно запускать svn commit для каждого git-фиксации между вашей веткой отслеживания svn и любыми HEAD в git. В вашем примере это три коммита – по одному для A, B и C –, так как git cherry-pick немедленно вносит изменения. Конечно, вы могли бы использовать git rebase -i, чтобы выкрикнуть эти коммиты вместе в одну ревизию, прежде чем запускать git svn dcommit, чтобы направить их на svn.

Выполняется git-svn полностью игнорирует все svn:mergeinfo. От git-svn man page:

Мы игнорируем все свойства SVN, кроме svn: executable. Любые необработанное свойства записываются в $GIT_DIR/svn/<refname>/unhandled.log

+0

Я использую TortoiseSVN, поэтому я не уверен, как вы это сделаете в командной строке, но я бы рекомендовал делать то, что в Tortoise называется Recording the Merge, где вы обновляете mergeinfo, но не делаете никаких фактические изменения в фиксации. Это теоретически предотвратило бы дальнейшие проблемы, если другие люди сливаются в контексте SVN, поскольку эти ревизии уже были «объединены» и могут вызвать ложный конфликт. –

1

Не должно быть никаких проблем с этим; Я делал это много раз на работе раньше. Кроме того, когда TortoiseSVN испытывал трудности с объединением целых филиалов в прошлом, я прибегал к переустановке ветвей темы на верхней части туловища и раздавливанию всех коммитов в один коммит, который похож по своей природе на вишневый. Он отлично работает.

+0

Но git svn обновит svn: свойства mergeinfo правильно, чтобы операции слияния слияния, выполненные с помощью svn merge, «увидели» вишневые кирки? – JesperE

+0

@JesperE: Нет. Для моей работы мне все равно, потому что svn: mergeinfo - ужасный взлом, и я использую Git для выполнения слияний в любом случае. :) – cdhowie

+0

Да, svn: mergeinfo - ужасный хак, но, к сожалению, у меня нет такой роскоши. Мои коллеги были бы очень раздражены, если бы я это сделал. – JesperE

9

ГИТ-Svn была серьезная проблема, связанная с вишней фиксаций:

Предположим, у вас есть совершить a1b2c3f9 который уже dcommitted в хранилище SVN:

$ git show a1b2c3f9 
    commit a1b2c3f9... 
    Author: Happy Dev <[email protected]> 
    Date: Mon Nov 14 13:01:38 2011 +0000 

    Commit message 

    git-svn-id: https://host/svn/branches/[email protected] 43fe5c0-... 

git-svn-id линия? Вот как git-svn понимает, где ваша фиксация лежит в репозитории Subversion.

Теперь вы хотите вишневого выбрать это совершить мастер филиал вы находитесь в данный момент:

$ git cherry-pick a1b2c3f9 

Если бы не было никаких конфликтов слияния, мерзавец создает новое обязательство, скажем, 9f3c2b1a и вот что у нас есть:

$ git show 9f3c2b1a 
    commit 9f3c2b1a... 
    Author: Happy Dev <[email protected]> 
    Date: Mon Nov 14 13:01:39 2011 +0000 

    Commit message 

    git-svn-id: https://host/svn/branches/[email protected] 43fe5c0-... 

Итак, Git создал коммит с точно таким же сообщением. Это вызвало серьезные проблемы. Бывшие версии git-svn отправили такую ​​фиксацию в неправильную ветку - ^/ветки/некоторая ветвь вместо ^/trunk/.

Эта проблема уже исправлена ​​в последних версиях Git. Но есть еще один, который все еще присутствует:

git-svn не оценивает механизм слежения за слиянием Subversion.

Subversion треки объединить информацию о выполненных вишневых кирки, поэтому команда

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

подстраивает SVN: mergeinfo свойство магистралью рабочей копии следующим образом:

+ /branches/some-branch: 1000 

Таким образом Subversion понимает, что эта конкретная ревизия уже была объединена в ветку ^/trunk/, поэтому она пропускает этот чанг е в дальнейшем слиянии.

При запуске git cherry-pick, а затем git svn dcommit хранилище Subversion не получает SVN: mergeinfo модификации.


Здесь идет отказ от ответственности:
В настоящее время я не работаю на SmartGit, но я работаю в тесном контакте с разработчиками SmartGit.

Syntevo Компания разработала SmartGit - отличная замена git-svn. Этот клиент Git решает все вопросы, которые я описал выше:

Итак, вы вишневого выбрать a1b2c3f9 фиксации:

$ git cherry-pick a1b2c3f9 

как результат вы получаете 9f3c2b1a фиксации, а затем вставьте его в Репозиторий Subversion. SmartGit делает все, чтобы сохранить слияния отслеживания информации, так ^/багажник/ отрасль получает необходимые изменения его СВН: mergeinfo свойство:

+ /branches/some-branch: 1000 

Вы можете выполнить Git вишневого выбрать либо из самой или с помощью SmartGit Интерфейс командной строки Git. Во втором случае сообщение о фиксации должно иметь строку git-svn-id линии источника вишневого источника.

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

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

Как и пользователь svn-via-git, я думаю, вам также это может быть интересно.

+0

Спасибо за информацию. Звучит многообещающе. – JesperE

+0

> Он намного превосходит git-svn и не имеет проблем. Это заявляется каждый на сайте SubGit, но я не могу найти ничего подробного, что они могут сделать и как они справляются с структурными различиями. – Peter