Как я могу разработать тест на ловушку и тест производительности для слияния файлов в разных системах контроля версий?

Question

Там, где я работаю, мы использовали Subversion в течение многих лет (очевидно, я не был здесь так долго). Здесь есть люди, которые предпочли бы использовать TFS, некоторые, кто предпочел бы перейти на Mercurial, а некоторые предпочли бы сохранить статус-кво. Другие элементы управления исходным кодом (Git, другие) не будут работать из-за плохой интеграции Visual Studio.

Самая большая проблема / страх того, что новый источник контроля ослабнет, это страх ветвления / слияния .

Я бы хотел построить тест, который бы напрямую обращался к тому, какой контроль исходного кода лучше объединить при помощи двух ветвей. Учитывая, что, вероятно, нет «демо» версии TFS, это может быть сложно. Тем не менее, это кажется интересной проблемой.

Чтобы проверить это, мне нужно знать следующее:

• Что такое алгоритм слияния, как правило, плохо?
• Могу ли я найти информацию о том, какой алгоритм слияния использует система контроля версий (в частности, TFS)?
• Могу ли я придумать какие-либо преимущества, которые одно слияние будет иметь по сравнению с другим?
• С какими типами файлов у большинства VCS возникают проблемы?

Что более важно, кто-нибудь из вас знает кого-то, кто уже сделал это?

Answer 1

Что касается TFS, у вас есть небольшой Учебник по ветвлению и слиянию , который может не учитывать тот факт, что филиалы стали первоклассными гражданами с TFS2010 .

* 1006.*

Вы можете увидеть проблемные слияния в этом Слиянии: hg / git против svn (изначально о Git, но его можно обобщить для других VCS): любой тип перекрестное слияние , как правило, трудно правильно обработать.

Оттуда вы также можете обратиться к:

• Чтоделает некоторые системы контроля версий лучше при слиянии?
• Почему в Mercurial ветвление и слияние легче, чем в Subversion?

Большинство VCS не будетобъединить двоичные элементы (кроме некоторых, таких как текстовые документы).

Answer 2

Я не уверен, что вы найдете много полезного в тесте производительности для различных инструментов. Все инструменты быстры в отношении разрешимых слияний. Проблема и точка сравнения в том, как часто они приводят к конфликтам. TFS 2008 и предыдущие версии были ужасны при разрешении конфликтов. 2010 год наравне с любой другой системой, которую я использовал, включая Git. Вы можете найти там недосказанных, но они думают о 2008 году (по общему признанию, очень плохо решают слияния для вас)

Ключ часто нажимать или тянуть. Если вы разветвляетесь, убедитесь, что вы часто вытягиваете из родительской ветви. Чем дольше тебя нет, тем больше шансов на конфликты. Это особенно верно для сгенерированных файлов, таких как файлы resx и .xxproj.