Являются ли слияния в Subversion более сложными, чем в Team Foundation System?

Question

Я привык использовать TFS, и теперь моя компания переходит на SVN для нового проекта (основная причина - лучше включить нашу кодовую базу java и .Net под тем же контролем исходного кода).

Мне дано понять, что слияния в Subversion трудны (Джефф упомянул это в своем последнем подкасте).

1. Какие проблемы с Subversion по сравнению с TFS?
2. Как смягчить? (в рамках подрывной деятельности или, как предложил Джефф, выбор другого источника контроля)

Одна сильная особенность, которую предлагает TFS, - это возможности автоматического слияния (значительно улучшенные в TFS2008, но пока не идеальные). Большинство слияний не требуют никаких действий со стороны пользователя. Это то же самое в Subversion?

Обновление - принятый ответ может прийти только от того, кто испытал большие слияния как в TFS , так и в Subversion , и может реально сравнить и сопоставить два. Знание, что «слияние в Subversion - это хорошо» или «TFS - это дерьмо», на самом деле не помогает мне принять решение, потому что оно подчинено. Если вы можете сравнить с другими альтернативами, отлично - это полезно. Но мой фокус - это подрывная деятельность против TFS.

Целевая группа, в которой я заинтересован, - 6-30 активных разработчиков.

Обновление 2 - есть ли кто-нибудь, кто объяснил бы, что слияния в SVN на самом деле проще, чем в TFS (с учетом инструментов)?

Answer 1

Я сделал большие слияния как в TFS, так и в Subversion. Кодовая база TFS была ветвью 1.5-> 2.0 приложения SharePoint с производственными изменениями, объединенными в кодовую базу 2.0. Слияние SVN было слиянием новых функций из форка в базовый источник.

Вы уже знакомы с TFS, поэтому я избавлю вас от подробностей, за исключением того, что инструменты changesets и TFS сделали этот процесс очень простым. Мы получили ошибку TF14087 из-за проблемы восстановления, но она была быстро устранена.

В SVN процесс был немного более ручным, потому что нам приходилось ориентироваться на конкретные версии файлов в SVN, а SVN проводил различие между файлами, что не давало нам гибкости, которую мы испытывали с наборами изменений в TFS (в таких случаях как «не все изменения в ChangesetA, но все изменения в ChangesetB»). В то время у нас не было отслеживания слияний, а дерево исходных текстов не было разработано для поддержки лучших практик отслеживания слияний в SVN.

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

Answer 2

Я не думаю, что слияния в Subversion вообще сложны для обычных случаев, взгляните на примеры, подобные this . Я нашел слияние восхитительно простым и легким; хотя некоторые сотрудники жалуются на то, что им больше нравится CVS, другие p4 и т. д. и т. д. Я подозреваю, что многое из этого связано со знакомством с другими инструментами, а не с техническим превосходством / неполноценностью.

Возможно, что более сложные (трехсторонние) слияния сложнее, но вопрос в том, являются ли они общими. Лично я рассматриваю сложные слияния (и долгоживущие ветви, сложное отслеживание ветвей, стратегии слияния и т. Д.) Запах гниения кода (или, я думаю, гниль SCM). YMMV.

Answer 3

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

Если слияние имеет для вас решающее значение, вы можете рассмотреть один из DVCS, которые превосходно сливаются, например git или mercurial .

Answer 4

Я использовал subversion в течение очень долгого времени, и позвольте мне сказать вам, слияние ужасно и абсолютно сломано. Я перешел на Mercurial, хотя я не пользуюсь распределенным материалом, просто чтобы получить работающее ветвление.

Разработка, согласно запросу Чтобы успешно выполнить слияние в SVN, вам нужно (ed) узнать номер версии, которую несла ветвь, которую не так сложно найти, если вы выполняете только одно слияние обратно в транк. К сожалению, иногда вам нужно несколько раз объединить (то есть получается, что для добавления функции сначала нужно было исправить ошибку) в ствол, или вы выполняете объединение между разными ветвями, что делает невозможным отслеживание какой версии номер принадлежит к какой ветви и что ранее было объединено.

Версия SVN, которую я использую, - 1.5.1, поэтому она должна работать с разработкой нового стиля, хотя, как мне показалось, я пропустил это.

Answer 5

Есть плюсы и минусы всех систем.

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

BR Johan

Answer 6

В некоторой степени не по теме, но если вопрос перехода с TFS для ваших Java-разработчиков все еще не решен, я бы порекомендовал вам взглянуть на Teamprise. Это инструмент, созданный только для разработчиков Java, использующих TFS. Он дает пользователю Java большую часть возможностей интеграции Visual Studio (а некоторые вещи даже лучше) в затмении.

http://www.teamprise.com/

(К вашему сведению, я никоим образом не связан с ними ...)

Vaccano