2009-06-05 4 views
6

Наша команда использует SVN для управления приложением приличного размера, и со временем сформировалась довольно сложная иерархия ветвей и тегов, которая основывается на базовом стандартном макете для хранилищ SVN, но более вложенный:Миграция сложной иерархии ветвей SVN в Mercurial

 
    |-trunk 
    |-branches 
    | |-releases 
    | | |-releaseA 
    | | `-releaseB 
    | `-features 
    |  |-featureX 
    |  `-featureY 
    |-tags 
    |-releaseA 
    | |-beta 
    | `-RTP 
    `-releaseB 
     |-beta 
     `-RTP  

(ветви особенности, очевидно, временные филиалы, но мы должны принять их во внимание, поскольку это не будет возможным, чтобы закрыть их все сразу в ближайшем будущем)

По нескольким причинам, но прежде всего потому, что слияния становятся все болью, мы считаем ng для переключения на Mercurial.

Основная проблема, с которой мы сталкиваемся сейчас, - это перенос существующей базы кода без потери нашей истории. Я пробовал несколько инструментов миграции (например, , hg convert и svn2hg), причем yasvn2hg является наиболее перспективным, но ни один из них, похоже, не справляется с вложенными иерархиями, но все они предполагают, что ветви и теги организованы в один плоский каталог соответственно.

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

Итак, Каков наилучший способ преобразования вложенной иерархии ветвей SVN, как это, в Mercurial?

Преобразование одной ветви за раз в отдельный репозиторий было бы весьма раздражающим, и я не уверен, что это будет правильный подход в первую очередь, в зависимости от того, как инструменты обрабатывают исторические слияния и должны знать все остальные отрасли?

+0

эй, я почти опубликовал тот же самый вопрос только сейчас. Хотелось бы услышать, если вы остановитесь на решении, задав вопрос. Как упоминалось ниже в комментарии, в моем случае наличие «клона» для вложенной ветви на самом деле не является решением, и я уверен, надеюсь найти способ импортировать ветки _as branches_ в HG без дублирования гор данных, разбив на много репо. –

ответ

2

Отличная статья, которую я читал. http://ww2.samhart.com/node/50

+0

В этой ссылке упоминается мое обоснование для разделения svn repo на несколько hg-репозиций. –

2

Вы должны действительно задавать такие вопросы на mercurial mailing list. Именно там работают разработчики Mercurial, и с течением времени было много вопросов миграции Subversion.

Это, как говорится, recent change может помочь вам - он утверждает, что позволить вам

[...] исправить даже самые плохо бесхозяйственно репозиториев и превратить их в хорошо структурированных Mercurial хранилищ.

Я сам не пробовал, поэтому не могу комментировать, насколько он эффективен для вашего конкретного случая.

+0

Спасибо, я посмотрю, смогу ли найти исправление, которое вы упомянули, и попробовать. Что касается списка рассылки, это вариант, который я обязательно изучу.Большинство хитов Google, которые я обнаружил в отношении миграции Mercurial, либо указывали на запись в блоге, либо SO, поэтому было удобнее первое место для запроса –

+0

Право. Я предложил это, так как я считаю, что стыдно распространять ответы как по вики, так и по списку рассылки, а теперь и по стеклу. Кроме того, в списке рассылки есть несколько человек, которые работали над этой конкретной частью кода. Если вам нравится IRC, я видел, как многие люди получали помощь в #mercurial канале на irc.freenode.net. –

Смежные вопросы