Mercurial "ветки вендора" из внешних репозиториев?
Я хочу сохранить проект в Mercurial, который содержит внешний код (который я могу изменить) из репозиториев Git и SVN. В SVN я решал бы это с помощью веток вендоров и копировал код, но я понимал, что в Mercurial лучше иметь разные репозитории для разных проектов, и при необходимости переключаться между ними.
Макет проекта будет таким:
- externalLibraryA [происходит из репозитория SVN] - ... с некоторыми дополнительными файлами от меня - externalLibraryB [происходит из репозитория SVN] - ... с некоторыми дополнительными файлами от меня - externalPluginForExternalLibraryB [происходит из репозитория Git]
В Subversion я бы создал vendor режиссёр trunk dir, сначала скопируйте все внешние библиотеки vendor, а затем в нужном месте в trunk, (Я думаю) Я могу сделать это и в Mercurial, с суб-репозиториями, но разве это лучший способ сделать это?
Я попытался настроить различные репозитории для внешних библиотек, но потом кажется, что я не могу вытащить externalLibraryARepo в externalLibraryA каталог моего основного хранилища? Он идет в основной каталог, что не то, что я хочу. Я также могу создать зеркальный репозиторий Mercurial и включить его в качестве вложенного репо в свой основной репозиторий, но затем изменения в этом подкаталоге отправляются в зеркальный репозиторий, а я хочу, чтобы они оставались в основном репозитории.
2 ответа
Это зависит от того, будет ли ваш код настраиваться вашей командой или нет. Наши команды добились больших успехов, поддерживая ветвь с именем "vendor" в репозиториях с нашими собственными настройками веток, названных по имени проекта. Этот код вендора затем легко включается в проект в качестве вложенного репозитория.
Предостережение в этом подходе: если активная разработка происходит в под-репозитории, лучше оставить его для прямого редактирования под-репозитория в качестве отдельного клона, в противном случае возникает необходимость обратить пристальное внимание на репозиторий верхнего уровня, чтобы избежать непреднамеренного увеличения ваш.hgsubstate перешёл на неверную ревизию и сломал вашу сборку.
Следите за слияниями репозитория верхнего уровня (вашего проекта) между версиями, которые указывают на разные именованные ветви вашего под-репозитория, так как это может привести к слиянию между ветвями "vendor" и "project" в под-репозитории, когда оно повторяется, что может быть нежелательно.
Обратите внимание, что эта функциональность может измениться и в будущем, так как в последние месяцы в списках рассылки mercurial-devel ведутся некоторые "теплые" дискуссии о будущем рекурсии субпозитория.
редактировать: я только что видел это обсуждение в связанных ссылках, которые, кажется, актуальны: /questions/15190665/vendor-vetvlenie-rtutnyij-stil/15190680#15190680
Вероятно, я бы просто сохранил это в одном репозитории - обратите внимание, что в приведенной вами ссылке они в конце концов используют свою систему сборки для объединения двоичного вывода из разных репозиториев. Я не совсем понимаю их обоснование.
Если основная проблема, которую вы пытаетесь решить, заключается в том, как обновить внешние компоненты чистым способом, я бы, вероятно, использовал для этого анонимное ветвление.
Т.е. добавить внешнюю библиотеку в ваш проект и ваши модификации. Убедитесь, что это работает. Тег с ExternalA-v1.0. Взломай свой реальный проект. Теперь у ExternalA, Inc. есть новая версия их материала. Обновите репо до тега ExternalA-v1.0. Импортируйте их новую версию и примените ваши модификации сверху. Commit. Теперь у вас есть две главы: одна с последней версией вашего кода (которая работает с ExternalA-v1.0) и одна с последней версией ExternalA (которая, возможно, не работает с вашим кодом). Тогда вы объединяете и примиряете их. Снова отметьте, теперь с ExternalA-v2.0. Повторите по мере необходимости.
Вы по-прежнему можете хранить свои внешние компоненты в отдельных репозиториях, но я предполагаю, что проекту, в котором они используются, нет необходимости постоянно обновляться с учетом изменений в нем - похоже, что весь смысл веток поставщиков заключается в том, чтобы иметь некоторую точку изоляции между иждивенцем и иждивенцами. Конечно, перемещение изменений из проекта externalA в проект, который использует этот проект, будет делом ручным (ну, в общем, копией, как в SVN на самом деле).