Насколько безопасны автоматические слияния в Mercurial?

Question

В Mercurial есть расширение fetch , которое можно использовать для эмуляции чего-то вроде svn update, то есть для объединения с входящими изменениями, даже не глядя на них. Но даже если вы не используете hg fetch, большинство ваших слияний будут «чудесным образом» работать, не приводя к конфликту. Это замечательно, но насколько безопасно доверять таким слияниям, чтобы быть допустимыми, скажем, Java-кодом?

Есть ли примеры, чтобы продемонстрировать, почему или когда этим слияниям следует (или не следует) доверять?

Answer 1

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

Рассмотрите следующий пример:

class A {

   public void methodA() {
     // do something here 
     // that should be great
   }

   public void methodB() {
     // And now I'll 
     // do something here
     // and it's gonna be good.
   }

   public void methodC() {
     // Finally, let's 
     // do something here
   }

}

Теперь вы начинаете работать и решаете добавитьнекоторые инструкции для methodC.
За это время сотрудник решил, что methodC по какой-либо причине должен быть помещен в верхнюю часть класса.

В итоге у вас будет две версии для слияния.
Ваш:

class A {

   public void methodA() {
     // do something here 
     // that should be great
   }

   public void methodB() {
     // And now I'll 
     // do something here
     // and it's gonna be good.
   }

   public void methodC() {
     // Finally, let's 
     // do something here
     // and here your marvelous changes
   }

}

И ваши коллеги:

class A {

   public void methodC() {
     // Finally, let's 
     // do something here
   }

   public void methodA() {
     // do something here 
     // that should be great
   }

   public void methodB() {
     // And now I'll 
     // do something here
     // and it's gonna be good.
   }

}

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

class A {

   public void methodC() {
     // Finally, let's 
     // do something here
   }

   public void methodA() {
     // do something here 
     // that should be great
   }

   public void methodB() {
     // And now I'll 
     // do something here
     // and it's gonna be good.
   }

   public void methodC() {
     // Finally, let's 
     // do something here
     // and here your marvelous changes
   }

}

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

Надеемся, что этот случай довольно редкий, и если изменений слишком много, mercurial попросит вас объединить классы вручную.

Answer 2

Я использую hg fetch все время.Я позволил ему автоматически тянуть / объединять / фиксировать, а затем я собираю + тестировать.Если это не удастся, вы можете либо hg backout последняя транзакция, либо просто исправить то, что сломалось, а затем зафиксировать новый набор изменений перед нажатием.

Answer 3

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

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

Answer 4

Я использую Mercurial на работе уже несколько месяцев.Общая команда состоит из 50+ разработчиков ПО и разделена на подгруппы из 5-10 разработчиков.Мы еще не увидели неудачного слияния, которое не было результатом:

1. родительский файл был поврежден / поврежден при переходе в слияние (т.е. ошибка кодирования)
2. неверное разрешениеконфликтов слияния разработчиком

Итак, мы были очень довольны результатами слияния для стандартных текстовых файлов (.c, .h, .pl, makefile, linkerfiles и т. д.).

Мы выявили случай, когда объединение является плохой идеей и может привести к некоторым проблемам, и это включает в себя автоматически генерируемый код или модели, сохраняемые в виде текстовых файлов.Mercurial не будет пытаться объединить бинарные файлы, но он с радостью объединит модели, автоматически сгенерированные файлы .c / .h и так далее.Вы можете указать стратегии слияния для каждого каталога или типа файла, но даже при наличии этих настроек может произойти несоответствующее слияние из-за предварительного слияния Mercurial.Вне этих случаев слияние ртути было для нас очень эффективным.

ps: если вас интересует случай модели / автогена, найдите предложение здесь .

Answer 5

Если вы с подозрением относитесь к процессу слияния, лошадь уже покинула сарай.

Скоординированное развитие требует только этого: координации. Вы не должны одновременно работать над одним и тем же сегментом кода. Означает ли это, что вы не работаете с одной и той же функцией, классом или файлом, зависит от ваших обстоятельств и масштаба ваших изменений, тема слишком глубокая для простого объяснения здесь.

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

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

Все это говорит о том, что большинство слияний, которые я сделал, прошли без проблем. Те, которые вызвали проблемы, стали известны как конфликты в процессе слияния, и этого было достаточно, чтобы побудить нас более внимательно изучить рассматриваемый код, а также, что более важно, методы, которые мы использовали для разделения нашей работы. Лучше сделать это правильно, но также трудно понять, что «правильно», пока вы не испортили пару раз. Это не значит, что мы не вводили логических ошибок и не тестировали весь наш код, но мир тоже не идеален.

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

Единственный реальный ответ - явно координировать ваши усилия заранее, а также инвестировать в методологию тестирования, такую ​​как TDD с модульным тестированием. Обвинение в слиянии - слабый соус.