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

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

18 голосов
/ 16 декабря 2010

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

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

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

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

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

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

Ответы [ 2 ]

18 голосов
/ 16 декабря 2010

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

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

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

blessed repository

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

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

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

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

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

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

2 голосов
/ 16 декабря 2010

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

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

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

...