Синхронизация изменений из дочернего репозитория Mercurial, созданного с помощью hg convert, обратно в его родительский репозиторий Mercurial

У меня есть родительский репозиторий A.

Я создал небольшой дочерний репозиторий B родительского репозитория, содержащий тщательно подобранный небольшой список подпапок для доступа другой команде с помощью hg-convert.

hg convert A B --filemap filemap.txt

где filemap.txt не переименовывает. Он включает только папки или исключает их. Такие как:

exclude *
include folder1
include folder2/subfolder1
include folder2/subfolder2
include folder2/subfolder3
exclude folder3_that_was_pulled_in_for_some_reason

Преобразование из A в B работает нормально. Я также могу повторно запустить команду hg convert, чтобы «протолкнуть» последующие изменения с A на B (здесь я использую термин push ...)

Но как насчет того, чтобы «протолкнуть» изменения с B обратно на A? Запуск hg convert B A без карты файлов воссоздает все коммиты в B обратно в A, поэтому у меня есть множество дублированных коммитов в A.

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


mercurial mercurial-convert
person persiflage    schedule 11.10.2013    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Для этого нет хорошего способа, поэтому convert не должен быть частью двунаправленного рабочего процесса. Можно использовать convert постепенно, так что вы можете переходить от A к B много раз, но вы не можете переходить от B к A. Вы можете попробовать hg export патчи от B и hg import их в A, и это, вероятно, сработает, но когда Затем вы hg convert снова переходите из A в B, они удвоятся, и слияние, вероятно, будет трудным.

Рассмотрите возможность разделения репо на два отдельных репозитория с общедоступным материалом в качестве вспомогательного репозитория для всего репо.

/projectname
    stuff.txt
    /folder1
    /folder3_that_was_pulled_in_for_some_reason
    /projectname-public
        /folder2/subfolder1
        /folder2/subfolder2

Когда projectname-public является вспомогательным репозиторием, его можно клонировать отдельно, выпускать отдельно, и вы можете принимать запросы на вытягивание, исправлять и легко объединять их.

Субрепозиторий не для новичков, но это проще, чем делать круговые операции на convert.

person Ry4an Brase    schedule 12.10.2013
comment
Спасибо за прямой ответ. Думаю, мой выбор - либо реорганизовать репо, либо отказаться от простой синхронизации. Вероятно, сделает последнее, поскольку синхронизация B обратно с A не так высокоприоритетна, как перемещение новых изменений с A на B. - person persiflage; 12.10.2013
comment
@persiflage, вы можете пожалеть об этом решении, если команда, работающая над B, начнет присылать вам множество ревизий, которые не могут быть тривиально интегрированы: ваша установка не имеет общего контроля версий - есть одно репо для вас и одно для другая команда, и вы ставите себе задачу поддерживать их синхронизацию с помощью внешних средств. - person alexis; 13.10.2013
comment
@alexis. Спасибо, я понимаю вашу точку зрения. Если бы интеграция изменений B обратно в A была бизнес-приоритетом, я бы выбрал подход субхранилища. В этом случае бизнес-приоритетом является передача изменений из A в B. В конце проекта B изменения B могут быть интегрированы обратно в A, но более вероятно, что проект B будет осиротевшим или исчезнет. в самостоятельном направлении. - person persiflage; 16.10.2013