С Mercurial, общая практика для создания 2 или 3 клонов того же проекта, что и в режиме ожидания?

Question

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

Прежде всего, клонируется ли временное репо из центрального репо или из нашего локального репо?

Кроме того, хорошо ли клонировать 2 или 3 репозитория из центрального репо на наши жесткие диски, поэтому, если мы работаем над функцией, использующей локальное репо 1, и нам нужно быстро исправить ошибку, мы можем для локального репо 2 выполните hg pull, hg up и исправьте ошибку, а hg push и исправьте ошибку, не затрагивая локальное репо 1?

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

Обновление: я думаю, что одна из рекомендуемых практик из ответов: : клонировать из центрального репо в локальное репо только один раз (и называть это локальное репо как «главное репо»), а затем клонировать из этого локального репо «по требованию», исправить срочную ошибку в репозитории tmp и отправить напрямую из репозитория tmp обратно в центральное удаленное репо? Однако разве не говорится, что во время разработки мы должны часто совершать коммиты (даже до того, как функция будет полностью завершена и не содержит ошибок), поэтому, если мы клонируем из локального репозитория в репозиторий tmp, клон не будет включать эти зафиксированные файлы как Что ж? А что, если срочное исправление потребует изменения файлов в локальном репо, находящихся в «промежуточном» состоянии (в середине разработки)?

Answer 1

Моя практика заключается в том, чтобы иметь «главный» клон центрального репозитория, а затем для каждой функции или исправления ошибки, над которой я работаю, я клонирую «главный». Когда я заканчиваю функцию, я возвращаю ее к «мастеру», а затем, когда я уверен, я нажимаю на центральную часть.

Вот некоторые Лучшие практики Mercurial

Answer 2

А что, если срочное исправление потребует изменения файлов в локальном репо, которые находятся в «промежуточном» состоянии (в середине разработки)?

Затем, как только выклонируйте локальное репо, извлеките прошлый коммит, прежде чем вы начали работать с основной веткой, которая вызвала «промежуточное» состояние, исправьте ошибку и вернитесь к удаленному мастеру.Это будет выглядеть примерно так:

@ (under development)
|
| @ (fixed a bug)
|/
|
o (last good commit)
|

В качестве альтернативы, вы можете клонировать локальное репо до «последней хорошей фиксации», исключая те, которые находятся в стадии разработки (с использованием hg clone -r <rev>).

Answer 3

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

Remote-Master - (клонировать / извлекать) -> локально-никогда не изменяемый клон - (клонировать / извлекать) -> локально-модифицированные-клоны - (выдвигать) -> Remote-Master

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

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

Answer 4

Я бы сошел с ума, пытаясь отследить состояние нескольких локальных клонов. Клонирование по требованию - путь. Если клонирование очень медленное, у вас есть два варианта:

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

• Если медлительность присуща Mercurial, возможно, вам следует вернуться к вопросу о том, предоставляет ли Mercurial то, что вам нужно в системе контроля версий.

Answer 5

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

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

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