Как вы управляете незначительными изменениями, которые вы хотите сохранить локально в Mercurial?

Я подумываю о переносе 14-летнего cvs-репозитория (без изменений) в Mercurial. Я думаю, что у меня есть все технические биты преобразования, но у меня все еще есть некоторые вопросы по эффективной работе в Mercurial.

Одна из вещей, которые я часто вижу в отдельных песочницах cvs для разработчиков (включая мою собственную), - это локальные незафиксированные изменения, которые не готовы быть отправленными на основную линию. Я понимаю, что это плохо. Большинство моих экспериментов с hg предполагают, что незафиксированные изменения - плохая вещь. Для этого достаточно слиться с ними. Так что я хочу знать, как другие люди, которые используют Mercurial в повседневном кодировании, справляются с этим. Как вы справляетесь с неполными изменениями в коде, когда приходит время обновить ваш репозиторий? Как вы справляетесь с локальными изменениями, которыми вы (пока) не хотите делиться с другими разработчиками?

Я справляюсь с этим так:

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

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

Я добавлю пару вещей.

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

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

Если бы у меня были более постоянные изменения, скажем, я хотел, чтобы файл конфигурации на моей машине разработки всегда указывал на локальный хост-порт 3333, а не на производственный сервер, то я бы хотел использовать расширение Mercurial Queues, которое поставляется с Mercurial и TortoiseHg. ,

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

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

Если вы сохраните их в рабочей копии, входящие изменения будут работать нормально, поэтому вам просто нужно избегать создания исходящих изменений, а это значит избегать их фиксации. Если файлы новые, это просто - не надо hg addих. Если они уже отслежены, вы можете специально исключить их из коммитов hg commit --exclude foo.txt. Если у вас есть большое количество файлов для исключения или вы будете исключать их из многих коммитов (например, для постоянного изменения в локальном файле конфигурации), посмотрите на расширение exclude .

Если вы готовы отложить изменения, у вас есть другой набор опций. Самое простое - просто использовать hg diffфайлы для создания патча, описывающего их, который вы храните в безопасном месте, а затем hg patch --no-commitповторно применить этот патч, когда вы захотите вернуть изменения. Вы можете сделать это Smoother, установив расширение сукна , на расширение чердака , или какой - либо другой родственник. Вы могли также использовать расширение очередей , но это использует кувалду, чтобы сломать орех. Вы можете даже просто зафиксировать изменения, затем обновить их до родительского и зафиксировать другую работу, оставив изменения в короткой анонимной ветке hg commit -m 'temporary branch' && hg up $(hg log -r 'parents(.)' --template '{node}')(хотя это может быть проще сделать вручную!). Тогда вам придется позаботиться о том, чтобы не продвигать этот набор изменений.

Два основных подхода используются для разделения потоков развития.

• Именованные Филиалы. Идея в том, что вы работаете над своей собственной веткой nmichaels_branch_of_awesome. Таким образом, вы можете зафиксировать свои изменения, не поджаривая чужую работу. Затем вы объединяетесь с другими людьми, когда вам нужна их работа, и когда приходит время для этой функции, вы переходите к более стабильной ветви для интеграции. Я предпочитаю названные ветви.

• Анонимный клон. Это создает отдельный репозиторий для вашей песочницы. Здесь вы играете до тех пор, пока не получите то, что хотите, затем (вероятно) сделаете патч MQ для ваших коммитов и перенеситесь туда, откуда вы начали. Мне не очень нравится этот подход, так как он требует управления каталогами и, возможно, работы с MQ, что может быть непросто. А с некоторыми репозиториями они могут стать немного большими для этого. Тем не менее, кажется, что это предпочитают разработчики Kiln.