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

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

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

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

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

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

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

Ответы

Ответ 1

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

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

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

blessed repository

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

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

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

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

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

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

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

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

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

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

Ответ 2

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

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

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