Использование Mercurial для разделения частной и публичной версии

Question

Как бы вы использовали Mercurial для решения следующей проблемы.

Предположим, у меня есть библиотека Core. Теперь я хочу разработать расширение для этой библиотеки под названием Extension. Я хочу физически отделить Core от Extension, т. Е. Скажем, что Core - это библиотека с открытым исходным кодом, а Extension - это закрытая библиотека, основанная на Core (может быть, она содержит некоторые вещи, которые я хочу сохранить в личном. Что угодно.). Очевидно, что я не хочу помещать весь источник в Extension в публичный репозиторий. Но, с другой стороны, я мог бы захотеть перенести некоторые изменения из Расширения в Ядро (если я решу «пожертвовать» часть Расширения Ядру) или наоборот (если я хочу включить исправления ошибок, скажем).

Как бы вы поступили так, минимизировав риск утечки Extension to Core (как только история будет отправлена ​​на общедоступный сервер, пути назад не будет!), Оставаясь гибкими, чтобы сделать это для определенных изменений. Ветви? Клоны? MQS? Что-то другое?

В настоящее время я знаком только с клонированием репозиториев, и мне очень нравится его простота.

EDIT: Я придумал эту схему, но не могу заставить ее работать под Windows. Два хранилища (ядро и расширение). В расширении есть две ветви , а также ядро ​​и расширение. Теперь вы можете зарегистрировать хук в репозитории в Mercurial, поэтому я бы хотел зарегистрировать хук pretxnchangegroup в репо Core, который запрещает чекины из ветви Extension, как это объяснено в книге Mercurial, За исключением того, что я не совсем понимаю, чтобы это работало под окнами. Итак:

• у кого-нибудь есть пример чего-то подобного (фактически, любой хук, который изменяет исход транзакции) под windows?
• Я все еще смогу использовать изменения трансплантата к вишенке от Расширения до основной ветви, верно?

Answer 1

После некоторого тестирования я собираюсь попробовать эту схему. Два основных репозитория и две именованные ветви, Core и Extension.

Один основной репозиторий Core, который должен содержать только базовые наборы изменений и источник. Таким образом, он должен содержать только наборы изменений из ветви Core. Это проверяется с помощью следующей ловушки репозитория в hgrc этого репо:

pretxnchangegroup.branch = hg heads --template "current branches: {branches} " | find "Extension" && exit 1 || exit 0

Выглядит немного странно, но в основном оно срабатывает после того, как пуш или пул завершены, но до того, как оно будет зафиксировано. В этот момент, если перехват не выполняется, транзакция откатывается. Таким образом, ловушка ищет набор изменений в ветви Расширения и терпит неудачу, если находит его - эффективно запрещая изменения Расширения для входа в репозиторий Core.

Второй репозиторий содержит как базовую, так и расширенную ветви и наборы изменений, и именно здесь происходит обмен наборами изменений между двумя филиалами. Обычное слияние с ядра на расширение и пересадка с расширения на ядро.

надеюсь, это поможет кому-то еще.

Answer 2

Расширение Forest позволяет вам хранить несколько репо как часть большого. Похоже, это может помочь здесь.

Answer 3

(как только история выдвинута, есть нет пути назад!)

конечно, есть ... вот что такое контроль версий!

Я не делал ничего подобного раньше, но похоже, что команда трансплантат будет полезна. Кроме того, вы можете иметь клоны клонов, и нажать на любой из них, и так далее.