Mercurial "ветки вендора" из внешних репозиториев?

Question

Я хочу сохранить проект в Mercurial, который содержит внешний код (который я могу изменить) из репозиториев Git и SVN. В SVN я решал бы это с ветвями вендоров и копировал код, но я понимал, что в Mercurial лучше иметь разные репозитории для разных проектов , и при необходимости перемещаться между ними.

Макет проекта будет таким:

 - externalLibraryA [comes from a SVN repo]
  - ...with some extra files from me
 - externalLibraryB [comes from a SVN repo]
  - ...with some extra files from me
  - externalPluginForExternalLibraryB [comes from a Git repo]

В Subversion я создал бы vendor dir и trunk dir, скопировал бы все внешние библиотеки сначала в vendor, а затем в нужное место в trunk. (Я думаю) Я могу сделать это и в Mercurial, с подкаталогами , но разве это лучший способ сделать это?

Я пытался настроить разные репозитории для внешних библиотек, но потом кажется, что я не могу вставить externalLibraryARepo в каталог externalLibraryA моего основного репозитория? Он идет в основной каталог, что не то, что я хочу. Я также могу создать зеркальный репозиторий Mercurial и включить его в качестве вложенного репо в свой основной репозиторий, но затем изменения в этом подкаталоге отправляются в зеркальный репозиторий, в то время как я хочу, чтобы они оставались в основном репозитории.

Answer 1

Это зависит от того, будет ли код вашей команды настраиваться вашей командой или нет. Наши команды добились больших успехов, поддерживая ветвь с именем «vendor» в репозиториях с нашими собственными настройками веток, названных по имени проекта. Этот код поставщика затем легко включается в проект в качестве под-репозитория.

Предостережение в этом подходе: если в подрепозитории идет активная разработка, лучше оставить его для прямого редактирования подрепозитория как отдельного клона, в противном случае возникает необходимость обратить пристальное внимание на репозиторий верхнего уровня, чтобы вы не t непреднамеренно поднимает ваш .hgsubstate вперед к неправильной ревизии и ломает вашу сборку.

Следите за слияниями репозитория верхнего уровня (вашего проекта) между версиями, которые указывают на разные именованные ветви вашего под-репозитория, так как это может привести к слиянию между ветвями "vendor" и "project" в под-репозитории как это повторяется, что может быть нежелательно.

Обратите внимание, что эта функциональность может измениться и в будущем, так как в последние месяцы в списках рассылки mercurial-devel о будущем рекурсии субпозитория происходили "теплые" дискуссии.

редактирование: Я только что видел эту дискуссию и в связанных ссылках, которые кажутся актуальными: https://stackoverflow.com/a/3998791/1186771

Answer 2

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

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

т.е. добавьте внешнюю библиотеку в свой проект и свои модификации. Убедитесь, что это работает. Тег с ExternalA-v1.0. Взломай свой реальный проект. Теперь у ExternalA, Inc. есть новая версия их материала. Обновите репо до тега ExternalA-v1.0. Импортируйте их новую версию и примените ваши модификации сверху. Commit. Теперь у вас есть две главы: одна с последней версией вашего кода (которая работает с ExternalA-v1.0) и одна с последней версией ExternalA (которая, возможно, не работает с вашим кодом). Итак, вы объединяете и примиряете их. Снова отметьте, теперь с ExternalA-v2.0. Повторите при необходимости.

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