SVN vs TFS branching

6yrop

У TFS-а есть существенное преимущество перед SVN. TFS сам сохраняет информацию о слияниях, и использует ее при следующих слияниях (поведение по-умолчанию). В SVN-е это делается вручную — при комите в комментарий записывается диапазон версий.
http://linfoline.homedns.org/svn-book-html-chunk/svn.branchm...
 
SubVersion does not track merge history. That's a deal-killer in my mind for large projects.
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=738720...
  

Но в тоже время команда merge в SVN очень гибкая, в TFS-е такой гибкости не наблюдается. Вот такая ситуация
 
Еще одним типичным применением для svn merge является откат изменений, которые уже были зафиксированы. Предположим вы спокойно работаете в рабочей копии /calc/trunk и выясняете, что изменения сделанные в правке 303, которые изменили integer.c, полностью ошибочны.
http://linfoline.homedns.org/svn-book-html-chunk/svn.branchm...
  

в SVN решается просто. А TFS-е стандартного способа отката ченджсета вообще нет, есть вспомогательная тулза, но по описанию там тоже геморойно (сам не пробовал). А такая потребность реально возникает!
Еще вот теоретически возможна ситуация, когда из ветки A выделили ветку B, после продолжительной работы c обоими ветками (взаимные мерджи и т.д.) решаем, что ветка B сейчас находится в самом правильном состоянии, и основную ветку A надо перевести в это состояние. Как это сделать в TFS-е, я не знаю .... :confused:
Update:
попробовал тулзу, вроде работает :)

6yrop

Как это сделать в TFS-е, я не знаю ....
теоретически можно откатить той тулзой ветку A до точки разветвления и потом сделать force-мердж, но это же через жопу

tokuchu

TFS
Чтозанах?
А чем всякие git, bzr, mercurial, darcs не устраивают, если нужно с мержами работать? У них вроде как с этим хорошо.

slonishka

Чтозанах?
нечто виндово-проприетарное, если правильно помню.
Оставить комментарий
Имя или ник:
Комментарий: