Как управлять параллельной разработкой с помощью Mercurial?

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

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

Допустим, у вас есть база кода в репозитории hg . Вы начинаете работать над сложной новой функцией A, затем ваш доверенный тестировщик сообщает о сложной ошибке B (у вас есть тестировщики, не так ли?).

Это тривиально, если (исправление) B зависит от A. Вы просто ci A затем ci B.

Мой вопрос в том, что делать, когда они независимы (или, по крайней мере, так кажется сейчас).

Я могу думать о следующих способах:

1. Использовать отдельный клон для B.
2. Используйте анонимные или именованные ветки или закладки в одном репозитории.
3. Используйте MQ (с патчем B поверх A).
4. Используйте разветвленный MQ (я объясню позже).
5. Использование нескольких MQ (начиная с версии 1.6)

1 и 2 описаны в отличном блоге @Steve Losh, ссылка на который дан из слегка связанного вопроса .

Тот самый Огромное преимущество 1 по сравнению с другими вариантами состоит в том, что при переключении с работы над одним делом на другое не требуется никакой перестройки, поскольку файлы физически разделены и независимы. Так что это действительно единственный выбор, если, например, A и / или B касаются файла заголовка, который определяет логическое значение с тремя состояниями и включается в тысячи файлов C (не говорите мне, что вы не видели такой устаревший код base).

3, вероятно, является самым простым (с точки зрения настройки и накладных расходов), и вы можете поменять порядок A и B, если B - небольшое и / или срочное исправление. Однако это может быть сложно, если A и B касаются одного и того же файла (ов). Это' s легко исправить фрагменты патчей, которые не применялись, если изменения A и B в одном файле (файлах) ортогональны, но концептуально это все еще немного рискованно.

4 может вызвать у вас головокружение, но это самый мощный, гибкий и масштабируемый путь. Я использую по умолчанию hg qinit с помощью -c , так как я хочу отмечать незавершенные патчи и подталкивать / извлекать их, но для того, чтобы понять, что вы можете выполнять ветвление, нужен концептуальный скачок. Репо MQ тоже. Вот шаги (mq = hg --mq):

1. hg qnew bugA ; внести изменения для A; hg qref
2. mq branch branchA; hg qci
3. hg qpop; mq up -rtip ^
4. hg qnew bugB ; внести изменения для B; hg qref
5. mq branch branchB; hg qci
6. Чтобы снова поработать над A: hg qpop; mq up branchA; hg qpush

Кажется безумием делать так много шагов, и всякий раз, когда вам нужно переключить работу, вы должны hg qci; hg qpop; mq up ; hg qpush . Но учтите следующее: у вас есть несколько именованных веток выпуска в одном репозитории, и вам нужно работать над несколькими проектами и исправлять ошибки одновременно для всех из них (вам лучше получить гарантированный бонус за такую ​​работу). Вы очень скоро потеряетесь с другими подходами.

Теперь, мои друзья-любители hg, есть ли другие / лучшие альтернативы?

(ОБНОВЛЕНИЕ) qqueue почти делает # 4 устаревшим. См. Элегантное описание Стива Лоша здесь .