与其他人相比，Team Foundation Server分支特征

Question

TFS的分支特征是什么？

---

早期分枝/重枝

例如，如果我们查看Perforce，Subversion，CVS等工具，我们会看到分支正在获取主干的副本。它是“早期分支”所有被定义为分支的文件，无论这些文件是否在该分支中被更改。

此方法开始在为整个文件树创建分支的决定时创建新版本的文件。

最大的缺点之一是，要在分支中进行的任何更改（通常在主干中），您需要将这些文件合并到这些文件的内部，因为它们具有“早期分支”。 / p>

晚分支/便宜分行

与更近期的工具（例如ClearCase，Plastic SCM，AccuRev，Mercurial，Git）相比，我们看到了一个较晚的（廉价）分支政策。

我们看到分支中的第一个新版本仅在分支上签入文件时创建。

这意味着当您希望重新绑定到分支的主干上发生更改时，不会发生未更改文件的合并。

TFS如何表现？

---

警告：我注意到当我们考虑DVCS工具时，我的术语并不准确。我认识Perforce有一种覆盖视图的圆形方式，但如果没有大量的劳动就不会这样做。

Answer 1

我被告知TFS比前者更接近前者。

Answer 2

注意：Version Control (ex Branching and Merging) Guide可以提供帮助。

在TFS Branching Guide - Lab.zip文件的“Single Dev Team Scenario 2.0.pdf”文档中，您将看到创建分支后跟一个提交（检查原始分支中的所有文件。） /> 使用的空间最小化，如Isolation for Collaboration页面中所述：

  

创建新分支并提交时，新分支中与源分支中的文件相同的所有文件都指向相同的内容。
  结果是分支占用的存储空间非常少，只有当分支文件与源不同时，存储空间才会扩展。
  即使文件发生变化，Team Foundation Server也会使用差异引擎来分析文件之间的变化，并再次优化存储空间。

因此，对于TFS2008来说它是重型分支（带有空间优化）。

在TFS2010中，分支是第一类对象，可以轻松地与简单文件夹分开。

Answer 3

我在TFS工作了5年，最近在去年转为GIT。

TFS有两个主要缺点（与GIT相比）：

1）没有Rebase概念。所有分支到分支的交互都是合并的。合并clobbers会更改历史记录，并隐藏提交注释中的所有有用详细信息。没有Cherry-pick，没有时间线重建。这导致无休止的父母散步，以及确定变革集历史的认真研究。

2）无底合并是一场噩梦。在TFS中，如果您在6个月前没有构建分支关系，那么您将不得不多次反向/转发集成以到达目的地主干。在git中，所有中继都是兼容的。

TFS有效，但有路障。一些路障确实损害了我们的交货时间。

到目前为止，我们已经在敏捷团队环境中使用GIT做了一些相当高级的事情，并且始终能够在几分钟内解决每个新的源问题而不是几小时或几天。促销等级是抽象的，可以临时交换。开发人员可以共享变更集的“节点到节点”，并在推送到公共存储库之前协同工作。

对MS没有任何冒犯，但我无法得到一个开箱即用的工具。

Answer 4

在tfs 2008中创建分支时，必须首先签入新的分支文件。一旦你检查它们的版本，分支开始分开原始。 您还可以在分支文件已分支之前跟踪它们的历史记录，但您需要安装TFS Follow Branch History Add-in for VS