SVN объединяет идемпотент? - PullRequest
Новая
       8

SVN объединяет идемпотент?

4 голосов
/ 21 июля 2009

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

Ответы [ 2 ]

4 голосов
/ 21 июля 2009

С теоретической точки зрения слияние не идемпотентно. Истинное слияние (которое Subversion поддерживает прерывистым образом 1 , поскольку v1.5 2 ) записывает коммит как имеющий двух (или более) родителей; обычно вы предполагаете, что результирующее дерево является комбинацией родительских коммитов. Однако большинство (но не все) системы контроля версий замечают, что один из родителей (один из филиалов в слиянии) является строгим предком другого, и вместо создания слияния он просто продвигает одну ветку. (Git вызывает эту ситуацию в прямом и обратном направлении).

После слияния мы имеем следующую ситуацию после "scm merge B", когда на ветке "A" (ниже есть попытка на диаграмме ASCII-art): 

---*---*---*---A---M               <--- trunk (branch A) 
                                  /
---*---*---*---B-/                     <--- branch (branch B)

Слияние коммит "M" имеет родителей "A" и "B". Теперь повторное «scm merge B» могло бы создать следующую ситуацию: 

---*---*---*---A---M---N               <--- trunk (branch A) 
                                  /       /
---*---*---*---B-/----/                     <--- branch (branch B)

где коммит слияния "N" имеет "M", а коммит "B" является родителем. (В некоторых случаях Bazaar может создать такую ​​ситуацию)

Отредактировано 22-07-2009:

Операция идемпотент , если несколько применений операции не изменяют результат. Объединение будет идемпотентным, если «scm merge branch_B && scm merge branch_B» даст тот же результат, что и одиночное «scm merge branch_B». Некоторые системы контроля версий имеют идемпотентное слияние; например, Git будет указывать «Уже в актуальном состоянии» при втором идентичном слиянии в строке и не создавать новый коммит. Некоторые системы контроля версий этого не делают; если я правильно понимаю, в зависимости от параметров, заданных для команды слияния, Bazaar может создать новый коммит слияния с родителями "M" (предыдущее слияние) и "B" (из branch_B) и деревом (содержимым), идентичным слиянию "M".

Сноска

  1. Клиент отслеживание слияний на стороне (если PhilM не правильно)? Информация о слиянии должна храниться в хранилище (в случае централизованной системы контроля версий, такой как Subversion, это означает, что она должна храниться на сервере)
  2. Вы можете использовать расширение svnmerge или SVK , которое является (полу) распределенной системой управления версиями, построенной поверх Subversion.
3 голосов
/ 21 июля 2009

Если вы используете Subversion 1.5 или более позднюю версию и ваши svn:mergeinfo свойства обновляются правильно, тогда да. Однако, поскольку Subversion использует отслеживание слияний на стороне клиента, если свойство svn:mergeinfo изменено таким образом, чтобы удалить / изменить историю слияния, вы, скорее всего, в конечном итоге получите файлы, оставшиеся в состоянии конфликта.

...