Адаптация svn: внешнее использование для перехода на Mercurial

Question

В корпоративной среде у нас есть структура хранилища SVN, которая выглядит следующим образом:

root
  libs
    shared_lib1
    shared_lib2
    private_lib
  public_code
  private_code

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

Теперь мне интересно, как лучше перейти от этой структуры к ртутному хранилищу.

1) Я мог бы близко смоделировать старую установку, используя ртутные субпозитории. ИЛИ ЖЕ
2) Я мог бы сделать одно большое репо для нас и три новых, меньших, отдельных репозитория для внешних партнеров (так что в основном они разрабатывают проекты) и обмениваться ревизиями между большим и отдельными.

С настройкой 1) в svn ветвление - это кошмар, потому что я по политике всегда должен разветвлять public_code, shared_lib1 и shared_lib2, когда я разветвляю root. Для этого мне нужно четыре раза вызвать svn branch и вручную изменить свойства svn: externals. Могу ли я с легкостью разложить основной репозиторий в Mercurial и автоматически получить новые ветки для всех вложенных репозиториев?

Когда я делаю настройку 2), файловая система будет отличаться между репозиториями. Например, у меня будет public_code/Makefile в репозитории "root", но файл будет просто "Makefile" в репо "public_code". Сможет ли Mercurial синхронизировать изменения между репозиториями? Как может выглядеть рабочий процесс?

Answer 1

С настройкой 1) в SVN ветвление является кошмаром, потому что я по политике всегда должен ветвиться public_code, shared_lib1 а также shared_lib2 когда я разветвляюсь root, Для этого мне нужно позвонить svn branch четыре раза и изменить svn:externals свойства вручную в три раза. Могу ли я легко разместить основной репозиторий в Mercurial и автоматически получать новые филиалы для всех вложенных репозиториев?

Нет, субпозитории не работают так. Именованные ветви в репозитории верхнего уровня не будут автоматически распространяться на субпозитории. Если вы сделаете 1.x переходите в свой код, тогда не понятно, что shared_lib1 также должен иметь 1.x ветка. Фактически, он, вероятно, не должен одновременно ветвиться в ветвях кода верхнего уровня, особенно если библиотека используется несколькими различными проектами верхнего уровня.

Когда я делаю настройку 2), файловая система будет отличаться между репозиториями. Например, я буду иметь public_code/Makefile в репо root но файл будет просто Makefile в репо public_code, Сможет ли Mercurial синхронизировать изменения между репозиториями? Как может выглядеть рабочий процесс?

Нет, вы не можете перемещаться между хранилищами, если создаете их таким образом. Вы можете использовать push / pull между репозиториями только в том случае, если они происходят из одного и того же "материнского" репозитория. Здесь звучит так, будто вы создадите три не связанных репозитория.

---

В такой ситуации вы должны тщательно оценить, почему у вас есть svn:externals в Subversion и как они отображаются в Mercurial. Они не являются заменой 1–1 для svn:externals, Вам также следует изучить инструментальную поддержку вложенных элементов - как в самом Mercurial, так и в вашем хостинге Mercurial, вашей системе продолжения сборки и т. Д. Я написал часть кода subcure Mercurial, а в Mercurial 2.0 все еще есть некоторые острые грани.

Короче говоря, то, что дают вам суб-репозитории - это очень тесная связь между подсистемами. Обычно этого следует избегать:-) Мы очень стараемся сделать наши программные системы слабо связанными, поскольку это дает нам гибкость.

Основным сценарием использования под-репозиториев является "репозиторий сборки", в котором вы отслеживаете точные версии ваших компонентов, которые вы использовали в данной сборке. Вы не можете попросить Mercurial отследить верхушку данной ветви в подпункте, он всегда будет отслеживать заданную ревизию в данном репозитории. Это то, что позволяет заново создать данную кассу позже: .hgsubstate Файл отслеживает точные наборы изменений, которые были извлечены в каждом подпункте.

Так что если ваш root репозиторий не используется для разработки, а только для сборки релизов, тогда субпозитории могут на самом деле отлично работать для вас. Рабочий процесс будет что-то вроде

$ cd root
$ cd libs/shared_lib1
$ hg pull
$ hg update 2.0
$ cd ../..
$ make test && hg commit -m "Updated to sharedlib1 2.0"
$ hg tag 2.3

Затем вы выпускаете версию 2.3 своего программного обеспечения, и Mercurial знает, что это зависит от версии 2.0 shared_lib1, Вы будете делать это время от времени, когда люди, ответственные за подкомпоненты, скажут вам, что у них есть новый релиз, готовый для вас. Ваш CI-сервер, конечно, может делать это каждую ночь, чтобы увидеть, работают ли компоненты вместе!

Подпозитории работают хуже, если разработчики работают в root непосредственно, и если они вносят изменения в подкомпоненты как часть их работы в root, Это указывает на слишком тесную связь между компонентами: если основной код зависит от точной ревизии подкомпонента, то подкомпонент должен быть непосредственно в основном коде. Также, hg commit в репозитории верхнего уровня будет повторять и использовать то же самое сообщение коммита в подпунктах, когда ui.commitsubrepos=True, (Значение по умолчанию было изменено на False в Mercurial 2.0.) Это часто нежелательно, и когда это имеет смысл, тогда подпункт очень тесно связан и должен быть частью репо верхнего уровня.

Итак, подведем итоги: используйте подпункты, если root это "репозиторий сборки". В противном случае вам следует либо встроить компоненты в репозиторий верхнего уровня, либо объединить части более свободно, используя что-то вроде Maven или аналогичное для управления зависимостями. Эти инструменты, как правило, позволяют вам сказать "пожалуйста, последняя версия root и все его зависимости ", а затем вы можете сделать официальный выпуск, когда будете довольны тестами. Эти сборки" моментального снимка "не могут быть точно воспроизведены, но это также не требуется - только в окончательных выпусках требуется строгое и точное отслеживание зависимостей.