Назад | Перейти на главную страницу

Как организовать резервное копирование локальных коммитов в Mercurial?

Мы переходим с SVN на Mercurial, и этот вопрос возник практически с первого дня. Итак, вот что:

Я стараюсь предоставить специальный сценарий резервного копирования, который будет делать что-то вроде этого:

hg push -fr REV URL

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

Итак, вопрос о REV и URL, а именно я вижу для них следующие варианты:

У меня нет большого опыта работы с Mercurial, поэтому мне очень сложно решить, какой вариант лучше. Кто-нибудь может посоветовать, пожалуйста?

РЕДАКТИРОВАТЬ

Теперь я понял, что мой вопрос раскрывает мое полное непонимание команды push. Конечно я не имел ввиду push -fr REV URL. На самом деле под REV я имел в виду ВЕТКУ, поэтому варианты должны гласить:

Далее, я понятия не имею, как перейти в другую ветку.

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

(Кстати: вы по логике упускаете четвертый вариант,

  • REV на разработчика, URL на разработчика.

что, однако, не имело бы особого смысла.)

ИМХО было бы полезно, если бы у каждого разработчика было свое хранилище резервных копий. Представьте себе ситуацию «восстановления»: вы теряете локальное рабочее пространство и вам необходимо восстановить его из резервной копии. Там вам не обязательно нужно чужое неопубликованное (или вам?). Это может навредить вам, если вы попытаетесь перейти к «настоящему» репо.

Все, кто работает в филиале, не будут работать хорошо, потому что это нарушит «повседневную работу», которая происходит в филиалах. default, testing, devel и / или experimental. (Просто примеры.)

=> URL на разработчика.

На вопрос, что должно быть продвинуто: просто все, так что не давайте -r аргументы.