Отправка обновлений в сокращенную ветку Mercurial

Question

У меня есть два связанных репозитория, мастер, который содержит ряд конфиденциальных файлов, которые не должны быть пропущены, и 'публичная' версия, созданная с помощью hg convert с --filemap, чтобы исключить конфиденциальные файлы и каталоги.

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

Если это возможно с Git, но не с Mercurial, миграция возможна, хотя это будет неприятно, поскольку некоторые разработки происходят на машинах с Windows. Подчиненный еще не видит активного использования извне, поэтому можно пристрелить его и воссоздать его другим способом, если это необходимо. Возможно даже, если это абсолютно необходимо, полностью сбросить мастер и повторно клонировать его из ведомого устройства, а затем оставить все чувствительные части полностью без изменений, но я бы предпочел не делать этого, поскольку некоторые из этих файлов меняются , и я бы хотел отслеживать эти изменения.

У кого-нибудь есть хорошие идеи?

Обновление: Я копался в документации по Git - может ли быть легко реализована команда "нажать все файлы, кроме этих" с помощью области подготовки Git?

Обновление 2: Это не помогает мне, но может помочь кому-то с подобной проблемой: вы можете использовать hg convert --filemap несколько раз, и он будет отслеживать только обновления для мастера, но это только работает, если целевой репозиторий записан через файловую систему, и не будет работать по проводам. Конечно, это также не поможет в обратном направлении.

Answer 1

Я думаю, мне нужно больше места, чем то, что даст мне поле для комментариев ...: -)

Позвольте мне попытаться объяснить, что я имею в виду под внутренним хранилищем. У нас есть два обычных, отдельных хранилища: «раб» и «хозяин». Вы помещаете все свои общедоступные файлы в «slave», а секретные файлы в «master»:

master/
  secret-file.txt
  another-secret.txt
  more-secrets.jpeg

slave-clone/
  public.png
  more-public.txt

Затем вы объединяете их, создавая новые клоны:

% hg clone master master-clone
% cd master-clone
% hg clone ../slave slave-clone

Теперь у вас есть клон «раба» внутри клона «хозяина»:

master-clone/
  secret-file.txt
  another-secret.txt
  slave-clone/
    public.png
    more-public.txt
  more-secrets.jpeg

В этом хранилище вы увидите, что «подчиненный клон» игнорируется всеми командами Mercurial, кроме случаев, когда вы меняете каталог на него. Так что вы можете сделать

% echo 'evil plans' > plans.txt
% hg add plans.txt
% hg commit -m 'Secret stuff'

и таким образом вы сделаете коммит во внешнем хранилище. Чтобы отредактировать некоторые общедоступные материалы, вы вводите 'slave-clone' и фиксируете там, как обычно.

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

Обратите внимание, что я предполагаю, что вы можете ограничить все публичные файлы в подкаталоге секретных файлов. Если вы переименуете «slave-clone» в «public» или «messages» или подобное, я не думаю, что это звучит слишком надуманным: -)

В противном случае вы могли бы что-то сделать с кучей символических ссылок, чтобы вы "присоединились" к репозиториям, вставив ссылки в один каталог.

Answer 2

Хорошо, похоже, что настоящий ответ таков: «Mercurial не может делать то, что вы хотите» (то есть иметь синхронизацию между хранилищем и ветвью, которая является строгим подмножеством этого хранилища), за исключением использования каких-то ужасно неудобных система, как очереди исправлений. Возможно, Git, но так как его порт Windows еще не готов к производственному использованию, я не стал вдаваться в подробности.

Однако оказалось возможным реорганизовать проект таким образом, чтобы можно было разделить открытые и закрытые части на отдельные репозитории с незначительной потерей истории. (На самом деле, он был разделен на три части, в то время как мы занимались этим - публичный раздел, публичный, но машинный раздел, который мы поместили в подкаталог local/ (так что его можно было клонировать к большей части машин с почти идентичные спецификации без необходимости поддерживать и объединять дополнительные ветви на несколько странных), а также закрытый раздел, который мы помещаем в подкаталог private/.) Уловка оказалась не в том, чтобы попытаться поместить очищенного ведомого в мастер, а в разделение частные / локальные части из мастера и поместите их как (псевдо) суб-репозитории в подчиненном репозитории на главном компьютере.

Этап 1 состоял в том, чтобы переместить файлы в каталоги private/ и local/, удалить их из главного репозитория и добавить их в .hgignore по мере необходимости, если замена символических ссылок могла бы создать проблемы на других машинах. К счастью, около 95% материалов, которые нам пришлось переместить таким образом, не зависели от местоположения, а остальное мы могли обработать вручную. Эти два каталога стали собственными репозиториями.

Этап 2, который мы в основном уже сделали: hg convert с использованием --filemap для создания общедоступной версии хранилища, в которой были удалены все следы личных данных. (На самом деле это потребовало небольшой настройки файловой карты: вам нужно исключить не только все текущие имена файлов личных данных, но также и любые имена файлов, которые они могли иметь в прошлом. Способность Mercurial отслеживать перемещения / переименования файлов кажется не совсем надежной. .)

В этот момент каталог .hg/ на главном сервере был перемещен в резервное хранилище, и из очищенного общедоступного репозитория было сделано новое извлечение. Затем мы запустили наши тесты, чтобы убедиться, что все работало, и начали клонировать новый базовый репозиторий и выбрали local репозитории для подчиненных машин, и проверили их, и все вроде бы нормально, хотя нам пришлось настроить несколько мест, где символические ссылки перестали работать (в основном на блоках Windows, хотя в одном месте, что довольно любопытно, на стороне Linux, и мне придется разобраться, почему не использовалась символическая ссылка, когда у меня будет свободное время, хотя мы решили проблема, когда было обнаружено, что этот конкретный файл может и действительно должен быть автоматически восстановлен).

Answer 3

Самым простым решением, вероятно, было бы просто поместить клона «раба» в «хозяина». Внутренний клон будет игнорироваться внешним клоном, поэтому, когда вы фиксируете изменения в секретных файлах, вы не рискуете смешивать их с общедоступными файлами. Толкание и вытягивание будут работать как обычно, и вам придется делать это дважды, один раз для внутреннего и один раз для внешнего.

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

Если вы изменяете публичный файл в смешанном репозитории, вы должны сначала убедиться, что вы обновили набор изменений, полученный из «подчиненного» репозитория. В противном случае вы не сможете зафиксировать и новый набор изменений в «ведомый». Так что, если вы находитесь на [s3]:

... [s1] --- [s2] ---[s3]
            /
... [p1] --/

и вы хотите обновить публичный файл, вам нужно сначала обновить до [p1]:

% hg update p1

, а затем отредактируйте и передайте

% hg commit -m 'Public change'
(created new head)

Ваш график истории теперь будет выглядеть так:

... [s1] --- [s2] ---[s3]
            /
... [p1] --/-[p2]

и вы захотите нажать [p2] на 'slave':

% hg push p2

и объединить его с [s3]:

% hg merge

после чего вы получите

... [s1] --- [s2] ---[s3] --- [s4]
            /                /
... [p1] --/-[p2] ----------/   

Другие решения можно найти внизу страницы NestedRepositories на вики Mercurial. Я считаю, что над Mercurial 1.3 работает над расширением subrepo, но мы должны это увидеть (дата релиза - 1 июля).