частичное слияние dvcs (git, hg отслеживание слияний)

Question

У меня один вопрос по поводу общих DVCS, включая Git и Hg.

В Git и Hg отслеживание слияний выполняется на уровне "commit" вместо уровня "file / directory".

Одним из «побочных эффектов» является то, что вы не можете легко выполнить «частичное слияние»:

• Вы изменили 30 файлов в своей ветке "feature_branch_x"
• Вы хотите объединить ТОЛЬКО файлы в (скажем) / kernel / gui

С помощью "отслеживания слияния на основе элементов" (Perforce, ClearCase, Plastic SCM <= 3.0) вы можете просто выбрать несколько файлов для слияния, затем проверить, а затем повторить слияние, и появятся ожидающие файлы. </p>

С Hg, Git: после слияния (есть способы сохранить файлы без слияния), устанавливается «отслеживание», и если вы повторяете слияние, не остается кандидатов на слияние.

Мой вопрос: как вы к этому относитесь?

Есть ли случаи, когда вы считаете "частичное слияние" обязательным? Вы можете жить без этого? (объединение с отслеживанием уровня commit / cset происходит намного быстрее).

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Я работаю на Plastic SCM , и мы перешли на отслеживание уровня "cset" в 4.0, но мы задаемся вопросом, может ли быть хорошей идеей остаться с "отслеживанием слияний на уровне элементов" "или даже разрешить оба.

Answer 1

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

Answer 2

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

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

Конечно, это неприятно объединять ветви, которые отклоняются в течение длительного времени.В мире DVCS эти монстр-слияния пытаются смягчить, чтобы объединить ранние и непрерывно отклоняющиеся ветви (скажем, одна ветвь является функциональной, а стабильная - это хорошая идея, чтобы часто объединять стабильную-особенность).Кроме того, git имеет возможность отслеживать решения конфликтов слияния (называемые rerere ), что помогает уменьшить боль при слиянии, когда вы пытаетесь выполнить одно и то же слияние несколько раз (например, когда «тренируетесь» слияние до окончательного завершения).).

Answer 3

Пабло, вот реальный пример, поддерживающий слияние на уровне элементов: давайте возьмем основную ветку M и ветку клиента C.Ветвь C была разветвлена ​​некоторое время назад, возможно, недели или месяцы назад, а M значительно выросла.Теперь вам нужно сделать оперативное исправление для клиента и, следовательно, изменить код в C.Кроме того, вам необходимо ввести изменение в M.

. Наш рабочий процесс будет заключаться в том, чтобы выполнить полное, правильное исправление в M, протестировать M и выпустить новую версию продукта общего назначения.Затем мне нужно объединить соответствующие части исправления с C, чтобы иметь возможность предоставить пользовательскую сборку для клиента, затронутого проблемой.Следовательно, мне нужно перевести некоторые изменения из M в C.Такая операция будет иметь следующие аспекты:

• некоторые файлы объединяются «как есть»,
• некоторые файлы объединяются вручную, но очень важно знать, что слияние произошло, *Файлы 1023 *
• , объединенные из M, не обязательно должны быть из самого последнего регистратора изменений в M, они могут охватывать несколько наборов изменений.

Таким образом, чтобы иметь возможность отслеживать такую ​​операцию при проверкеИстория хранилища, «потоки данных (кода)» между файлами должны быть записаны в каждом отдельном случае.Результирующий «набор изменений слияния» будет состоять из автоматических слияний 1: 1, а также слияний, скорректированных вручную.

ОБНОВЛЕНИЕ: Соотношение скорости и юзабилити: насколько я понимаю, вы делаете ставку на функциикак действительно хорошее слияние .И я держу пари, что большинство пользователей не будут заботиться о суперскорости - но они будут заботиться о действительно хорошем слиянии.

Около десяти лет назад добавление 1000 файлов в ClearCaseзаняло 10 минут.Потребовалась 1 минута, чтобы добавить их в Subversion.Вот почему мы выбрали Subversion вместо ClearCase.Однако, если бы ClearCase заняла 2 минуты, мы бы - скорее всего - выбрали ClearCase из-за его тогда еще лучших функций.

Если я получу хорошие, рабочие функции, которые поддерживают реальный мир разработка коммерческого программного обеспеченияСценарии Меня не волнует, будет ли это на 50% быстрее или медленнее, чем моя текущая VCS (Subversion).Но, с другой стороны, если вы предоставляете плохие функции и / или что-то, что блокирует юзабилити по сравнению с другими инструментами VCS, пользователи не переключатся.

Чтобы сделать вывод об объединении на уровне изменений или на уровне элементов: придерживайтесь свободы - и это, по крайней мере, с моей точки зрения, слияние на уровне элементов.

Answer 4

из Объедините некоторые файлы сейчас, а некоторые позже :

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

Answer 5

ИМХО, SCM, получивший наиболее подходящее для этого ветвление / слияние, был PRCS, который поддерживал безболезненные частичные слияния с полной историей для каждого элемента. Это позволило вам иметь такие вещи, как ветки для каждой платформы и объединяться между ними, не опасаясь, что изменения, характерные для платформы, «перетекут» в другую ветку. Используемый алгоритм описан здесь;

http://prcs.sourceforge.net/merge.html

Больше всего я скучаю по слияниям, в которых основа и обе ветви различаются, она выполняет трехстороннее слияние для каждого файла и в первый раз запрашивает «ваши», «свои» или «слияние "и он запомнит ваш ответ по умолчанию для следующего слияния.

Когда я использовал его, я обнаружил, что переход / слияние настолько безболезненный и интуитивно понятный, что я использовал их все время, и это никогда не казалось сложным. По какой-то причине ветвление / слияние с hg и git никогда не было таким безболезненным.