Преобразовать репозиторий в более старую версию (без редкого журнала)

Question

Наша команда использует Mercurial для контроля версий, с центральным хранилищем, расположенным на общем сетевом диске (т.е. мы не используем сервер).Наша компания ограничивает то, что мы можем установить на наших компьютерах, и у всех была версия Hg 4.6.Один из членов команды использовал права администратора, он должен установить последнюю версию TortoiseHg (4.9).Это, по-видимому, привело к тому, что центральное хранилище было преобразовано в новейшую версию.Теперь другой член команды, со старым Mercurial, не может вытащить из центрального хранилища.В нем говорится, что

хранилищу требуются функции, неизвестные этому Mercurial: sparserevlog

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

Answer 1

С 4.9, новые репозитории будут создаваться с использованием sparse-revlog по умолчанию. Однако существующие репозитории остаются нетронутыми . Они остаются в том же формате, в котором были созданы.

Как избежать проблемы при создании репозитория

Чтобы пользователи, обновившиеся до создания sparse-revlog репозиториев, не могли установить в своей пользовательской конфигурации следующее (hg config -e)

[format]
sparse-revlog = no

У вас есть глобальный контроль над конфигурацией ваших пользователей?

Понижение рейтинга существующих репозиториев

Если вы хотите понизить версию только что созданного репозитория, вы должны сделать следующее:

1. добавить следующее в конфигурацию хранилища (hg config -l)

[format]
sparse-revlog = no

2. пробег hg debugupgraderepo --run (с 4.7 или новее)

Обновление существующих репозиториев

Если вы хотите обновить существующее созданное хранилище, процесс аналогичен:

1. добавить следующее в конфигурацию хранилища (hg config -l)

[format]
sparse-revlog = yes

2. пробег hg debugupgraderepo --run (с 4.7 или новее)

---

Примечание: страница https://www.selenic.com/mercurial/hgrc.5.html#format устарела. Веб-сайт для Mercurial был https://www.mercurial-scm.org/ в течение нескольких лет.

Answer 2

Обычно должна быть возможность дать команду hg во время операции клонирования НЕ использовать определенный, более новый формат репо.

Для этого есть определенные параметры конфигурации, как показано в документации :

Параметр конфигурации: format

usegeneraldelta

Включить или отключить формат репозитория "generaldelta" ... Включен по умолчанию.

dotencode

Включить или отключить формат репозитория "dotencode" ... Включен по умолчанию.

usefncache

Включить или отключить формат репозитория "fncache" ... Включен по умолчанию.

usestore

Включить или отключить формат хранилища "store" ... Включен по умолчанию.

Однако по какой-то причине в списке нет опции, соответствующей новейшему формату репо, который, как отмечено ввопрос "sparse-revlog" ( задокументировано здесь ).

Может быть, это просто недосмотр документации, я не уверен.

Предполагая (надеясь), что это так, и основываясь на ответе на другой вопрос , выможет быть в состоянии повторно клонировать, используя команду, подобную этой:

hg clone --config format.usesparserevlog=0  <source> <dest>

Если опция usesparserevlog существует и распознается, ей потребуется hg, чтобы НЕ использовать этот формат, что означает более старый предыдущий форматдолжно быть тем, что вы получаете, и будет совместимо с вашими локальными клиентами hg.

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

Answer 3

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

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

Согласно документации Отсутствует требование раздел Понизьте рейтинг своего хранилища по сети :

Поскольку все версии Mercurial могут взаимодействовать по сети, старый клиент может просто извлечь из хранилища, обслуживаемого новым Клиент:

# run this on the new client
$ hg serve
listening at http://hostname:8000/ (bound to *:8000)

# run this on the old client
$ hg clone http://hostname:8000/ downgraded-repo

Поскольку вы уже не используете hg serve, это, очевидно, не будет работать автоматически. Но вы можете использовать его временно. Примерно так:

1. Настройка временного hg serve, работающего на некоторых ПК. (В идеале, ИТ-ограничения не помешают этому.) Это должно служить вашему центральному репо.

2. Определение всех клонов репо, которые необходимо исправить. (Может быть, отменить все, которые не нужны для сохранения работы здесь.) Они должны быть только изменены (выдвинуты / вытянуты) клиентом THG 4.9.

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

4. Следуя приведенному выше примеру, выполните повторное клонирование с временного ПК hg serve на новые локальные клоны во всех случаях, когда они необходимы.

5. Восстановите любую резервную копию для новых клонов (это худшая часть и может быть очень болезненной). Я думаю, что это должно быть сделано вручную; может быть, есть умный подход diff / patch, который был бы проще.

6. Отключить темп hg serve экземпляр

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

Альтернатива / вариант - вы можете запустить hg serve на каждом ПК каждого разработчика, который использовал THG 4.9, и сделать так, чтобы каждый из них независимо перекодировал с локального хоста. Это может обойти любые ограничения ИТ, если это абсолютно необходимо. (Но если у вас нет ИТ-ограничений, на самом деле не имеет значения, где работает hg serve).

---

Если у вас очень большое количество затронутых разработчиков / клонов, я не уверен, что этот подход лучше. С одной стороны, если бы вы смогли привлечь своих ИТ-специалистов к обновлению всех пользователей до новейшей версии hg, это могло бы быть намного проще в целом.