Обойтись без частичной фиксации «Меркуриального пути» - PullRequest
12 голосов
/ 10 июня 2010

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

  1. Я работаю над какой-то большой функцией, и у меня есть значительная часть кода - или, возможно, несколько значительных частей кода - по частям по всему гаражу, совершенно непригодна для регистрации, возможно, даже не компилируется .
  2. Приходит срочный запрос на исправление ошибки. Исправление локальное и не затрагивает код, над которым я работал.
  3. Я исправляю свою рабочую копию.

Что теперь?

Я посмотрел " Изменения при выборе Mercurial cherry для коммита " и " лучшие практики в Mercurial: ветвление против клона и частичные слияния? ", и все предложения кажутся быть расширениями различной сложности, от записи и полки до очередей.

Тот факт, что для этого, очевидно, нет какой-либо основной функциональности, заставляет меня подозревать, что в некотором смысле этот стиль работы - Doing It Wrong. Как бы выглядело Mercurial-подобное решение для этого варианта использования?


Отредактировано для добавления: git, напротив, кажется, предназначено для этого рабочего процесса: git add файлы исправлений, не git add ничего другого (или git reset HEAD что-то, что вы, возможно, уже добавили ) git commit.

Ответы [ 6 ]

8 голосов
/ 11 июня 2010

Вот как бы я справился со случаем:

  1. имеет ветку разработчика
  2. имеют ветви функций
  3. есть личный филиал
  4. имеет стабильную ветвь.

В вашем сценарии я бы часто делал коммиты на мою ветку вне функциональной ветви.

Когда пришел запрос, я бы hg up -r XYZ, где XYZ - это число оборотов, которое они запускают, затем выделил бы новую ветвь функции от этой (или up branchname, как угодно).

Выполните работу, затем объединитесь в стабильную ветку после того, как работа будет протестирована.

Вернитесь к моей работе и объединитесь с верхним узлом фиксации ветви функций, таким образом объединяя два потока усилий.

6 голосов
/ 10 июня 2010

Много полезных функций для Mercurial предоставляется в виде расширений - не бойтесь их использовать.

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

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

3 голосов
/ 11 июня 2010

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

3 голосов
/ 10 июня 2010

Вы бы клонировали репозиторий (т.е. создали ветку исправления ошибок в терминах SVN) и сделали бы исправление оттуда.

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

1 голос
/ 13 июня 2010

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

1 голос
/ 12 июня 2010

В дополнение к тому, что Санта сказал о ветвлении, являющемся вашим другом ...

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

...