Должен ли ртутный подкаталог быть подкаталогом основного репозитория?

Question

Мой проект состоит из кода в следующих местах

C:\Dev\ProjectA
C:\Lib\LibraryB
C:\Lib\LibraryC

В настоящее время каждая из этих папок является полностью независимым хранилищем Mercurial. Проект A постоянно меняется, библиотеки B и C редко меняются.

В настоящее время я отмечаю каждую версию Project A по мере ее выпуска и (когда я помню) помещаю соответствующий тег в репозитории Library B и C.

Могу ли я улучшить это с помощью суб-репозиториев? Требуется ли от меня сделать Библиотеку B и C подкаталогом проекта A?

Если библиотеки B и C должны быть подкаталогами проекта A, что мне делать, если я хочу запустить проект D, который использует библиотеку B, но никак не связан с проектом A вообще?

Answer 1

Если библиотеки B и C должны быть подкаталогами проекта A, что мне делать, если я хочу запустить проект D, который использует библиотеку B, но никак не связан с проектом A вообще?

Любой проект может существовать как самостоятельно, так и одновременно как суб-репозиторий другого проекта. Я объясню, предложив рабочий процесс.

Прежде всего, каждый из ваших проектов (A, B, C) должен иметь благословенное хранилище, которое где-то публикуется:

Вы можете запустить hgwebdir на своем собственном сервере или использовать службу хостинга Mercurial, такую ​​как Bitbucket или Kiln. Таким образом, разработчики получают центральный авторитетный пункт для извлечения / извлечения изменений, и у вас есть что сделать для резервного копирования.

Теперь вы можете заставить клоны этих репозиториев работать двумя способами:

• напрямую клонировать ваш проект. Например:

  hg clone http://bitbucket.org/LachlanG/LibraryB C:\Lib\LibraryB
  

• и / или создать определения под- репозитория, поместив .hgsub файл в корне ProjectA со следующим содержанием:

  libraries/libraryB = http://bitbucket.org/LachlanG/LibraryB
  libraries/libraryC = http://bitbucket.org/LachlanG/LibraryC
  

Эти определения под-репозитория говорят Mercurial, что всякий раз, когда проект A клонируется, он также должен помещать клоны библиотеки B и библиотеки C в libraries папка.

Если вы работаете в проекте A и делаете коммит, то ваши изменения в libraries/LibraryB а также libraries/LibraryC будет совершено, а также. Mercurial запишет, какая версия библиотек используется проектом A в .hgsubstate файл. В результате, если вы hg update чтобы увидеть старую версию проекта, чтобы увидеть, как все работало на прошлой неделе, вы также получите соответствующую версию своих библиотек. Вам даже не нужно делать теги:-)

Когда ты hg push Проект A вносит изменения в благословенный репозиторий, Mercurial также позаботится о том, чтобы сначала перенести изменения субпозитория в их собственное происхождение. Таким образом, вы никогда не будете случайно публиковать изменения проекта, которые зависят от неопубликованных изменений библиотеки.

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

Answer 2

Вы действительно можете объявить B а также C подпункты проекта A (они будут отображаться как подкаталог, как описано в http://mercurial.selenic.com/wiki/Subrepository).
Это улучшит ваш механизм релиза, поскольку позволит вам:

• получить все репо в одном месте (A и под)
• ссылаться на точный тег B а также C под A
• помечать каждого суб-репо первым, если они имели какие-либо изменения
• тег A с информацией о B а также C теги в нем (любой клон A сможет получить точные теги B а также C использован A)

Вы также можете объявить B как подотчет Dнезависимо от A, Что вы делаете в A (в отношении B) не будет иметь никаких последствий для B используется в D,