(Еще один) Какое лучшее преобразование из SVN-репозитория в HG-репозиторий (ы)? - PullRequest
0 голосов
/ 04 марта 2010

В моей компании имеется большое хранилище Subversion (SVN), и по разным причинам мы рассматриваем возможность перехода на Mercurial (HG). Я надеюсь выучить идеи «лучшей практики» для нашей ситуации.

Наш SVN-репозиторий довольно монолитен и выглядит примерно так:

  • Ствол
    • Python_Project_1
    • Python_Project_2
    • Python_Shared_Code
    • Flex_Code
    • ObjC_Code
    • ...
  • филиалы
    • Python_Project_1_Release_1.0.x
    • ...
  • теги
    • Python_Project_1_Release_1.0.0
    • ...

В настоящее время мы являемся единственными потребителями любого нашего кода и других ресурсов в репозитории, но одна из причин переключения заключается в том, что мы можем / будем делиться некоторыми частями нашего кода с другими потребителями. Итак, наши проекты будут разделены на следующие категории доступности:

  • Личный код (доступен только нам)
  • Общий код (предоставляется непубличным партнерам)
  • Публичный код (предоставляется через лицензию с открытым исходным кодом)

Кроме того, чтобы подчеркнуть это, некоторый код (например, папка Python_Shared_Code в приведенном выше примере с репозиторием SVN) используется совместно для разных проектов и поэтому должен быть легко доступен для любых проектов Python (Private Code), и может потребоваться доступны для внешних потребителей (общий код или открытый код).

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

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

Обновление: этот вопрос похож - но не идентичен - на несколько других вопросов, которые ранее задавались:

Основным отличием от предыдущих вопросов является идея «доступности» и общего кода. Некоторые из проектов взаимосвязаны (например, Python_Project_1 и Python_Shared_Code), а некоторые могут нуждаться в совместном использовании с внешними объектами (например, общий код и открытый код). Концепция разделения одного монолитного SVN-репозитория на несколько HG-репозиториев обсуждалась, но я не нашел никакой концепции ни одного из типов совместного использования, обсуждавшегося ранее.

1 Ответ

1 голос
/ 04 марта 2010

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

И в этот ответ Я предлагаю использовать либо подпункты (которые готовы ), либо (мое предпочтение) систему сборки, которая извлекает зависимости из локальной сборки, такой как ivy.

...