Какова лучшая стратегия Mercurial для клонирования / репозитория?

Question

Там может быть:

1) просто клонируйте из удаленного репо по мере необходимости (каждый новый может занять 20 минут и 500 МБ)

2) клонировать 2 локальных из удаленного репо, оба 500 МБ, всего 1 ГБ, поэтому всегда есть 2 локальных репо для работы с

3) клонировать 1 локального из удаленного репозитория, назвать его «мастер», а затем не трогать этого мастера, а клонировать других локальных из этого мастера по мере необходимости

Я начал использовать (1), но когда есть быстрое исправление ошибки, мне нужно сделать клон, и это занимает 20 минут, так что метод (2) лучше, потому что есть 2 независимых локальных репо все время.

Но тогда иногда репо становится «странным», потому что есть слияния, которые наносят ущерб, и когда это зафиксировано на удаленном репо, любое слияние локального репо, которое отображается в hg outgoing, приведет к повреждению позже, когда мы снова нажмем, поэтому мы просто удаляем это локальное хранилище и снова клонируем из удаленного, чтобы начать «заново», снова через 20 минут. (На самом деле, мы можем сначала использовать локальное репо 2, переименовать локальное репо 1 в repo_old, а затем перед сном или перед возвращением домой сделать клон снова)

Является ли (3) лучшим вариантом? Потому что на Mac мастер занимает 500 МБ и 20 минут, но другие локальные клоны работают очень быстро и занимают намного меньше 500 МБ, потому что он использует жесткую ссылку на Mac (как узнать, сколько дискового пространства без содержимого с жесткой связью? ). И если использовать (3), как мы делаем коммиты и push? Предположим, мы клонируем из удаленного репо в локальное как «master», а затем клонируем локальные как «clone01», «clone02», 03 и т. Д., Затем мы работаем внутри clone01, а затем, когда необходимо срочное исправление, мы идем чтобы освоить, выполните hg pull и hg update и перейдите к clone02, а также выполните hg pull и hg update и закрепите его на clone02, протестируйте его и hg commit, hg push для мастера, а затем перейти к мастеру, и сделать hg push там? И затем, когда проект clone01 будет завершен, снова перейдите к мастеру, извлеките, обновите, перейдите к clone01, извлеките, обновите, объедините, протестируйте, подтвердите, нажмите, перейдите к мастеру, нажмите для удаленного репо? Это много шагов!

Answer 1

Возможно, в вашем случае лучше подойдет четвертый вариант: Mercurial Queues , которые хранятся в локальном хранилище Mercurial.

Используя MQ, вы можете:

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

Вам не нужно хранить патчи в локальном репозитории, но это хороший бонусный вариант, который стоит рассмотреть.

Глава 12 из Mercurial: полное руководство объясняет процесс довольно подробно.

Answer 2

Я не знаю, правильно ли вы понимаете космические соображения.При клонировании локального репозитория Mercurial будет использовать жесткие ссылки на каталог .hg, реальный репозиторий, который не занимает дополнительного места.Рабочий каталог занимает место (хотя, надеемся, не 500 ГБ!), Но каталог .hg выглядит только так, как в зависимости от инструментов, которые вы используете для проверки.

Если вы делаете clone -U, вы создаете клон безрабочий каталог, и он должен почти не занимать дополнительное пространство и создаваться практически мгновенно.

Я всегда сохраняю clone -U центрального репо в неизмененном состоянии, а затем создаю из него клоны по мере необходимости.Я толкаю прямо из этих клонов обратно в удаленный репозиторий.

Answer 3

Mercurial Queues выглядят действительно мощно, но я никогда не давал себе времени прочитать всю эту документацию, просто чтобы отложить мою текущую работу сработать небольшую ошибку.

Я использую расширение чердак .

Это будет так:

...working happily, but then there is a quick bug fix...
$hg shelve work
...quickly fix the bug...
$hg ci
$hg unshelve
...continue with work

Иногда я получаю идею, но нет времени по-настоящему поиграть с ней. Чтобы я не забыл это.

...working happily, idea drops in...
$hg shelve work
...start a unittest for the idea or some other unfinished piece of code, enough to sketch the idea
$hg shelve idea
$hg unshelve work
...continue with work
$hg ls
   idea
*C work