Будет ли работать дополнительный Mercurial-репозиторий "push -f" / только для резервного копирования?

Question

Мы настроили наш собственный рабочий процесс Mercurial, который отлично работает для нас. Однако меня интересует кое-что: возможно ли создать какой-нибудь «мусорный» репозиторий, который в основном был бы местом, где каждый пользователь всегда мог бы «нажать -f» для своих наборов изменений и где мы бы никогда ничего не делали, кроме «push -f»

То есть: целью этого хранилища будет , а не , чтобы интегрировать / объединить / вытащить. На самом деле это будет не частью нашего рабочего процесса. Это действительно было бы «место для резервного копирования всех наборов изменений».

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

Я только что выполнил тест с тремя пользователями, выполняющими «push -f», и теперь это выглядит следующим образом (обратите внимание, что родительский элемент рабочего каталога остается в самом низу, в наборе изменений 0, и навсегда остается там):

$ hg glo | grep -v user: | grep -v date
o  changeset:   3:4337a665659f
|  tag:         tip
|  parent:      0:ab3e3171d569
|  summary:     1st change by user B
|
| o  changeset:   2:2349e3eed60d
|/   parent:      0:ab3e3171d569
|    summary:     1st change by user C
|
| o  changeset:   1:10405f5e0994
|/   summary:     1st change by user A
|
@  changeset:   0:ab3e3171d569
   summary:     Init

Будет ли это работать, если пользователи начнут извлекать данные из других репозиториев, объединять их работу и т. Д .?

Другими словами, это будут репозитории, в которых решение проблем слияния не будет проблемой, и где «push -f» и создание новых заголовков будет приветствоваться, и где родитель рабочего каталога будет всегда остается на "changeset 0". Его единственная цель - служить папкой «резервного копирования наборов изменений» (например, для резервного копирования наборов изменений, которые еще не были интегрированы в наш реальный рабочий процесс).

Будет ли это работать и имеет ли это смысл?

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

Answer 1

Да, это будет работать просто отлично. В вашем «мусорном» хранилище будет просто куча голов.

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

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

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

Answer 2

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

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

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

Другой вариант, который, я уверен, вы рассмотрели, - это отдельный процесс резервного копирования для ПК локального разработчика. Возможно, что-то автоматизировано и в фоновом режиме, как Карбонит ?

Надеюсь, это поможет.