LINUX.ORG.RU

Переход с SVN на HG


0

2

Решил потренироваться с переходом с SVN на HG.

  • В качестве тестового примера взял КуМир (http://lpm.org.ru/kumir2/).
  • Используя snvsync сделал локальную копию репозитория. С ней получается быстрее конвертация и анализ изменений.
  • Далее начинаются проблемы. Если использовать hg convert то:
    • получаем набор независимых веток, но по ним нормально виден процесс работы.
    • теряется вся что было где-то до 984 ревизии, когда код из корневой директории всё таки начал переноситься в trunk. Т.е. до этого никаких brunches и trunk небыло.
    • теряются директории playground и testing, но с ними надо разбираться отдельно, находя подходящее место в новом проекте.

Собственно приходи к вопросам:

  • как добавить всё что было до этого (984 SVN-ревизии)?
  • как свести ветви в единое дерево?
  • как быть с дополнительными директориями playground, testing находящимися и сейчас в корне?

Запихивать всё в один каталог, мне бы не хотелось, т.к. получающиеся сейчас ветви достаточно длинные и сливать их тупо в одну, мне кажется, не красиво.

★★★★★

svn практически не записывает информацию о том, какие ветки были смержены. Так что, получить из свновской истории нормальный DAG - задача фактически невыполнимая, особенно если использовался свн старше чем 1.6.

provaton ★★★★★
()

сначала сконвертить в git, там переколбасить в нормальную ветку.. а потом в перенести в hg. вся история будет в нормально виде...

denis_ka
()

Прошу прощения, чисто из любопытства интересуюсь - чем вызван интерес к Mercurial? (полностью согласен, замечательная DVCS)

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

Так получилось, что первым я попробовал hg, когда на него перешли hedgewars.

AlexVR ★★★★★
() автор топика
Ответ на: комментарий от provaton

svn практически не записывает информацию о том, какие ветки были смержены. Так что, получить из свновской истории нормальный DAG - задача фактически невыполнимая, особенно если использовался свн старше чем 1.6.

Мержи мержами, а svn copy прекрасно описывает какой файл от куда был скопирован.

AlexVR ★★★★★
() автор топика

Первый вопрос «как добавить всё что было до этого (984 SVN-ревизии)?» снят, я для начала сконвертил всё до ревизии 980, потом поочерёдно добавил ещё 4 ревизии, а затем все оставшиеся. Как теперь бы всё объединить в одно дерево?

AlexVR ★★★★★
() автор топика

Не надо сводить ветви в единое дерево, надо сделать бранчи в одном репозитории, если они и так не сделались.

Sorcerer ★★★★★
()
Ответ на: комментарий от AlexVR

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

Просто попробуй все инструменты конвертации, которые есть в наличии. Если не выйдет - значит не выйдет. ИМХО, это не стоит того, чтобы париться сильно.

provaton ★★★★★
()

В общем застрял на следующем:

  • Нашёл, что на этапе 980-984 SVN-ревизий происходило копирование содержимого корня репозитория в директорию trunk. точнее всё что было в ревизии 980 переместилось в папку trunk к 984.
  • Из-за этого делаю:
    hg convert file:///.../kumir-svn/ kumir-hg-svn -r980
    hg convert file:///.../kumir-svn/ kumir-hg-svn
    
  • в тоге получается три дерева.
    • первое - все изменения до 980 SVN-ревизии включительно.
      o  набор изменений:  979:ec66072f8cc0
      |  пользователь:     victor
      |  дата:             Tue Feb 24 11:20:25 2009 +0000
      |
      o  набор изменений:  978:0f4d964c20b4
      |  пользователь:     victor
      |  дата:             Tue Feb 24 10:52:21 2009 +0000
      |
      ...
      |
      o  набор изменений:  0:ea63e4298616
         пользователь:     kumir
         дата:             Wed Apr 02 11:34:38 2008 +0000
         сводка:           Версия 1.6
      
    • второе - trunk с одинм правильно определенным ответвлением и
      o  набор изменений:  2703:5f1dcd808106
      |  метка:            tip
      |  пользователь:     mordol
      |  дата:             Fri Feb 10 17:44:35 2012 +0000
      |
      ...
      |
      o  набор изменений:  1114:dd21dad40f23
      |  родитель:         1111:e0f11a7f1e01
      |  пользователь:     mordol
      |  дата:             Thu Feb 26 13:09:01 2009 +0000
      |
      | o  набор изменений:  1113:924cf32c6c68
      | |  ветка:            1.6
      | |  пользователь:     suboch
      | |  дата:             Wed Mar 11 13:06:43 2009 +0000
      | |
      | o  набор изменений:  1112:98d20b921d66
      |/   ветка:            1.6
      |    пользователь:     kumir
      |    дата:             Wed Feb 25 14:24:24 2009 +0000
      |
      o  набор изменений:  1111:e0f11a7f1e01
      |  пользователь:     kumir
      |  дата:             Tue Feb 24 12:38:28 2009 +0000
      |
      o  набор изменений:  1110:e920bce5a29b
         родитель:         -1:000000000000
         пользователь:     kumir
         дата:             Tue Feb 24 12:13:04 2009 +0000
      
    • третье - дерево версий 1.7.х
      o  набор изменений:  1109:e4145ec814c8
      |  ветка:            1.7.1
      |  родитель:         1097:e78ac96ec4d0
      |  пользователь:     victor
      |  дата:             Mon Sep 20 10:54:15 2010 +0000
      |
      | o  набор изменений:  1108:bcd40a0904b3
      | |  ветка:            1.7
      | |  пользователь:     victor
      | |  дата:             Mon Oct 11 16:41:22 2010 +0000
      | |
      ...
      | |
      | o  набор изменений:  1098:4293ff95c77a
      |/   ветка:            1.7
      |    пользователь:     victor
      |    дата:             Mon Sep 20 11:32:07 2010 +0000
      |    сводка:           Fix for 1.7.2
      |
      o  набор изменений:  1097:e78ac96ec4d0
      |  ветка:            1.7
      |  пользователь:     victor
      |  дата:             Tue Sep 14 12:53:44 2010 +0000
      |  сводка:           Install fix
      ...
      |
      o  набор изменений:  986:dc4811b2f1b0
      |  ветка:            1.7
      |  родитель:         984:c0694b29d0a2
      |  пользователь:     victor
      |  дата:             Fri Apr 16 09:05:40 2010 +0000
      |
      | o  набор изменений:  985:0c18108d05ad
      |/   ветка:            1.7.0
      |    пользователь:     victor
      |    дата:             Fri Apr 16 09:04:21 2010 +0000
      |    сводка:           Copied 1.7 to 1.7.0
      |
      o  набор изменений:  984:c0694b29d0a2
      |  ветка:            1.7
      |  пользователь:     victor
      |  дата:             Thu Jan 21 10:50:52 2010 +0000
      |  сводка:           BugFix: make recompilation after modules load
      |
      ...
      |
      o  набор изменений:  981:68aa9910a426
         ветка:            1.7
         родитель:         -1:000000000000
         пользователь:     victor
         дата:             Wed Jan 13 10:52:20 2010 +0000
      
  • Ревизии 979:ec66072f8cc0 и 1111:e0f11a7f1e01 содержат одинаковые наборы файлов. т.е. они с точки зрения файлов одинаковы. Как поизвести слияние в этой точке?
AlexVR ★★★★★
() автор топика
Ответ на: комментарий от stevejobs

Да и проблемы с ветками точно такие же.

AlexVR ★★★★★
() автор топика
Ответ на: комментарий от AlexVR

Пробовал hg rebase, но постоянно возникают конфликты с изменёнными файлами, и не могу понять, что является локальной, что удалённой, а что предыдущей версией.

Если через mq, то накатываются патчи успешно, но нужно разбивать на не разветвляющиеся куски и теряется информация об именах веток.

AlexVR ★★★★★
() автор топика
Ответ на: комментарий от AlexVR

Пробовал hg rebase

Ты пытаешься исправить структуру графа с помощью rebase?

но постоянно возникают конфликты с изменёнными файлами

Если для создания правильной структуры merge'ей ты готов править граф руками, то я бы посоветовал делать так:

пусть у нас есть последовательные ревизии транка T0, T и T1, и завершающая ревизия бранча B, причем T - это результат merge T0 и B; тогда тебе следует выполнить merge T0 и B, выбросить его результат, заменив его содержимым T, сделать коммит, и сделать rebase транка, начиная с T1, поверх новой ревизии.

Это если я правильно понял твою задачу :)

не могу понять, что является локальной, что удалённой, а что предыдущей версией.

Мой hg help rebase говорит о source и destination: «Rebase uses repeated merging to graft changesets from one part of history (the source) onto another (the destination)».

tailgunner ★★★★★
()
Ответ на: комментарий от AlexVR

То есть???

У нас все комментят на русском (кроме пары человек). Импортируется ОК.

Что ты делаешь, чтобы всё сломалось? Юзаешь не-юникод?

stevejobs ★★★★☆
()
Ответ на: комментарий от stevejobs

Ну что уж сделать, что я умею только git clone.

Пробовал сконвертировать в git, получил одну ветвь. Чего и не хотелось. Как разбить всё на ветви с учётом, что до 984 SVN-ревизии никаких trunk, branches не было не знаю. Если есть реальные предложения, готов выслушать, может и начну разбираться с git, а то пока меня в полной мере устраивает hg.

З.Ы.: Конвертацией занялся чисто ради повышения скилов, те проекты что были у меня в SVN переносились легче некуда. А когда попался КуМир, решил на нём и тренировать, он достаточно геморойный с точки зрения структуры хранилища.

З.З.Ы.: Если есть возможность, попробуй и сам, может лучше выйдет, заодно можно будет реально помочь проекту.

AlexVR ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.