Обобщение 3-way merge

Fri, 21 Mar 2014 15:23:42 GMT

Допустим, у нас есть функция 3-way merge, которая из трех версий O[rigin], A, B однозначно¹ делает версию C

Как нетривиально² обобщить эту функцию на такие случаи:

1. есть R1 (предок) и 3 головы (Ra:R1, Rb:R1, Rc:R1)

2. есть R1 (предок), Ra:R1, Rb:R1, и две головы (Rx:[Rb,Ra] и Rc:R1)

Как-то так. Мне главное чтоб сохранилось свойство консистентности, т.е. чтобы "в итоге" все, получив все наборы ревизий, пришли без дополнительных коммуникаций к одинаковому исходу.

Т.е. чтобы если ПОСЛЕ мержа примера (1) участники узнали что кто-то вбросил голову Ry:[Ra,Rb] то оно смержилось в то же самое, во что смержится пример (2)

В терминах git/hg: мне надо чтобы после того как все один раз push --force, дождались когда пушнут все остальные и pull - автомерж выдал одинаковый результат

В качестве дополнительной инфы у ревизии есть автор, все ревизии от одного автора упорядочены по времени "до/после", но время ревизий двух разных авторов сравнивать нельзя. Т.е. vector clock.

--
1. т.е. merge(O,A,B) === merge(O,B,A), что достигнуто, например, лексикографическим упорядочиванием A, B по хэшу от их содержимого.
НО мерж не коммутативен, т.е. m(A,m(B,C))!=m(m(A,B),C)
2. решению задачи удовлетворяет тривиальная функция которая всегда возвращает null, но это, очевидно, не то)

UPD: предложили посмотреть http://en.wikipedia.org/wiki/C3_linearization , http://en.wikibooks.org/wiki/Understanding_Darcs/Patch_theory , смотрю
UPD2: да, я знаю про Operational Transformation и Commutative Replicated Data Types, это скорее второе.

comments

git vs mercurial

Thu, 22 Nov 2012 00:18:16 GMT

Накопился определенный опыт работы с одним и с другим.

В общем:
Git: it works, but you have to learn it, tune it and tweak it.

Mercurial: it just works. you can tune it if you want, but it just works.

Еще с гитом я успел повлетать в пачку неприятных моментов когда пуш/пулл тупо не проходили, или репозиторий корраптился. Хорошо, что есть reflog.

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

В гите такое же действие приходит к тому что эмм надо долго шаманить с настройками, прежде чем пройдут особо крупные коммиты. Можно? Можно. Удобно? Не очень.

Хотя "непроходимость коммитов" случалась даже на мелких репозиториях, если делать рефакторинг.

С меркуриалом "history is sacred". Кому-то это нравится, кому-то нет. Мне - нравится.

Гит, напротив, должен быть приятен тем, кто подрабатывает в министерстве правды и правит коммиты задним числом.

Итого, для себя для продакшена - меркуриал. Гит неплох, но отвлекает. Меркуриал - просто и естественно становится частью рабочего процесса.

Плюс, "windows is a first-class citizen for mercurial". Hg Workbench на первый взгляд страшен, но уже через пару дней реально удобная тулза. Тестеров и джуниоров она тоже не пугает, что немаловажно.

А, да. SVN остается для особо сикретне проектов, где важна необходимость ограничивать доступ с гранулярностью до папок и оправдан оверхед на неудобные мержи.

Как-то вот так.

comments

wizzard

Обобщение 3-way merge

git vs mercurial