Подвижный hg, я делаю его правильно?

Похоже, вы отлично разбираетесь в концепциях, но у вас есть некоторые странности и некоторые вопросы, я поразим их списком ниже:

1. commit не принимает параметр --rev.Он фиксирует текущий рабочий каталог как новую ревизию, родительский элемент (или родительский элемент, если это слияние) - это то, что возвращает hg Родители , то есть всегда то, что вы сделали в последний раз hg update .
2. ваш hg push --rev bugfix1 -f не требует -f в очень новых (1.5+) версиях mercurial. Исторически предупреждение «вы создаете новую голову» обычно означало, что вы забыли выполнить слияние, но теперь, если новая голова представляет собой новую именованную ветвь, предупреждение подавляется.
3. Если бы я был вашим человеком, который делал экстренное исправление ошибки на моем локальном компьютере, я бы просто создал новый клон, сделал ветку и исправил там. Если вы настроили конфигурацию вашего веб-сервера / веб-приложения для поддержки того, что вы можете разрешать новые экземпляры в новых местах пути легко / автоматически
4. В вашей промежуточной среде я признаю желание, чтобы они тестировали исправление ошибки независимо от функции, и это хорошо идея, ваша команда QA не должна объединяться. Сделайте / позвольте разработчикам объединиться, и пусть команда QA перенесет исправления слияния в свою рабочую область. Например, набор изменений разработчика, созданный на шаге 3 DEV, уже обеспечивает надлежащую интеграцию исправления и того, что должно было быть, поэтому попросите команду QA вытащить эту ревизию, которая будет в ветке «по умолчанию». Точно так же после того, как QA утвердил исправление и будет готов перейти к функции, попросите их вытащить из разработчика набор изменений, созданный на этапе разработки 5.

Помните, что слияние - это тоже кодирование - человек, выполняющий слияние, делает выбор. о том, что должно и чего не должно быть. Специалисты по контролю качества могут быть на это способны, но это работа разработчика.Кроме того, зачем делать это дважды? Обычная передача для этого - что-то вроде «QA, вытащите ревизию 897a9d9f9a7 и протестируйте, пожалуйста, разработчики». Если вы хотите пофантазировать, у вас может быть такой тег, как 'readyforQA', который разработчики перемещают по ветке 'default' по мере продвижения (в этом примере они добавили hg tag после шагов 3 и 5 и пусть QA знает, что есть что-то новое.

Единственный совет, который я вам дам, - не пытайтесь перестроить процесс. DVCS приводят к некоторому бессистемному способу работы, это немного пугает сначала, но имеет тенденцию работать. Вы обнаружите, что подгруппы и пары людей имеют клонов, о которых вы никогда не знали, и, в конце концов, если у вас есть несколько твердых правил, таких как «ничего не идет в производство без предварительного прохождения через QA "остальное вроде само собой работает.