Previous Entry Share Next Entry
2016-01

Merge Tool Evaluation

Наткнулся тут на такие вот измерения

http://www.infosun.fim.uni-passau.de/spl/SSMerge/#samplesystems

количество конфликтов, количество конфликтнутых файлов, etc.

но, по-моему, оценивать надо не это, а (раз уж у нас есть бэклог существующих мержей) edit distance до варианта мержа, выбранного в итоге человеком.

т.к. что мы вообще хотим? хотим чтобы меньше работы при мерже было, ну и вот она конечно пропорциональна количеству "конфликтов вообще", но edit distance все же явно точнее

This entry was originally posted at http://wizzard.dreamwidth.org/361534.html. It has comment count unavailable comments. Please comment there using OpenID.

  • 1
justy_tylor March 22nd, 2014
А для какого проекта это всё оценивается?

Метрика то будет одна - снижение стресса пользователей. То есть, не "меньше работы", а "меньше ощущения пиздеца". Возможны ситуации с edit distance в один символ между труднообнаружимой багой после автомёржа и ручным исправлением. И специфика языка исходников тоже влияет.

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

wizzard0 March 22nd, 2014
Да, снижение стресса - хорошая метрика.

Это пока не имеет конкретных применений.

vit_r March 22nd, 2014
Вопрос не в том, как лучше состыковать, а сколько будет в состыкованном ошибок. Потому ручная сборка всегда разумнее автоматического слияния.

wizzard0 March 22nd, 2014
Вопрос в том, как уменьшить когнитивную нагрузку при ручной стыковке

vit_r March 22nd, 2014
Есть тулы, показывающие разницу двух файлов. Многие из них позволяют также показывать общего предка.

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

wizzard0 March 22nd, 2014
> Есть тулы, показывающие разницу двух файлов. Многие из них позволяют также показывать общего предка.

эээ, я в курсе, если вдруг что. у меня и BeyondCompare есть, и KDiff3 есть, и Compare++, и Araxis Merge.

> Просто один подгружает новые изменения к своему, проверяет и передаёт дальше по цепочке.

Ну да.

vit_r March 22nd, 2014
Задача только в том, чтобы организовать дело так, чтобы изменения были в разных файлах, в крайнем случае в разных частях одного файла, причём не было бы наведённых зависимостей.

109 March 22nd, 2014
причём в общем виде задача не решается :)

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

vit_r March 22nd, 2014
Кого интересует компилируется или не компилируется, если вопрос в том, есть ли в коде ошибки или нет. А это определяется только головой и правильным контролем изменений.

109 March 23rd, 2014
здесь вся речь об авто-мёрдже, как я понимаю. кого интересует ручной?

vit_r March 23rd, 2014
Мердж должен быть не "ручной", а поддерживаемый тулами. К сожалению, ни один не умеет показать, зачем и почему какая-то строчка была добавлена или выкинута.

Впрочем, в нормальных конторах даже на изменение одной строки кода проводят ревью.

wizzard0 March 23rd, 2014
В моей идеологии надо, чтобы "хоть что-то" мержанулось, при пособничестве всяких доп правил, хинтов и т.д., а потом юзер имел возможность исправить, если ему не понравится.

И, да, мержаю я (в данный момент) не код, а JSON-обьекты в wysiwyg-редакторе (аля Google Wave), не текстом естественно.

vit_r March 23rd, 2014
Страшно подумать, как мучаются люди, не зная о базах данных :-D

wizzard0 March 23rd, 2014
База данных подразумевает локи и транзакции.

Ни то, ни другое в данном случае (нужно офлайновое редактирование) не подходит.

wizzard0 March 23rd, 2014
в смысле "продукт на выходе" это rich text document, JSON там в потрохах.

(Deleted comment)

Re: оффтоп, но мб интересно

wizzard0 March 22nd, 2014
я слежу за этим проектом. но он под AGPL и вообще весь слишком политически окрашен чтобы его можно было брать в продакшен(

max630 March 22nd, 2014
это что? автоматический резолв конфликтов? для обычного случая девелопмента?

по-моему, тухлое дело - при пересекающихся больших изменениях там переписывать всё надо

что можно сделать - мержить не большие изменения, а маленькие. Тогда и резолвить просто. Есть такой например: https://github.com/mhagger/git-imerge

wizzard0 March 22nd, 2014
Да, я согласен про то, что большие изменения - это зло

sleepy_drago March 23rd, 2014
для промышленного применения лучше иметь бетонную гарантию что если конфликтов не обнаружено то мержилка ничего не нафантазировала. Так что извините все попытки игр с расстоянием редактирования надо сразу пресекать. Разумеется это все начинает играть с определенного размера проекта =) но факт остается фактом.

  • 1
?

Log in

No account? Create an account