Team Foundation Server 分支特性，与其他特性相比 [英] Team Foundation Server branching characteristics, compared to others

问题描述

TFS 的分支特性是什么?

What are the branching characteristics of TFS?

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

If we look at the tools Perforce, Subversion, CVS, for instance, we see that branching is taking a copy of the trunk. It is "early branching" all of the files which are defined to be branched, irrespective of whether those files are changed in that branch.

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

This methodology starts creating new versions of files, at the time the decision to create a branch is made, for the entire tree of files.

最大的缺点之一是，在该分支之外(通常在主干中)所做的任何更改，如果您想引入该分支，都需要将这些文件逐文件合并到内部，因为它们已经早期分支".

One of the biggest disadvantages is that any changes made outside that branch (typically in the trunk), that you want to bring into the branch, require per-file merges inwards of these files as they have "early branched."

与较新的工具(例如，ClearCase、Plastic SCM、AccuRev、Mercurial、Git)相比，我们看到了延迟(廉价)分支策略.

In comparison with more recent tools - for example - ClearCase, Plastic SCM, AccuRev, Mercurial, Git - we see a late (cheap) branching policy.

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

We see that first new versions in a branch are only created when a file is checked in on a branch.

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

This means that when changes happen on the trunk that you wish to rebase into your branch, no merges for unchanged files occur.

TFS 的行为如何?

警告:当我们考虑 DVCS 工具时，我注意到我的术语并不准确.我知道 Perforce 有一种迂回的方法来覆盖视图，但它不是没有大量的劳动就完成的.

caveats: I note my terminology is not exact when we consider DVCS tools. I recognise Perforce has a round-about way of overlaying views but it's not done without great labour.

推荐答案

注意:版本控制(前分支和合并)指南可以在这里提供帮助.

Note: the Version Control (ex Branching and Merging) Guide can help here.

在TFS 分支指南 - Lab.zip 文件，您将看到创建分支之后是提交(检查原始分支中的所有文件.
如隔离协作 页面:

In the "Single Dev Team Scenario 2.0.pdf" document of TFS Branching Guide - Lab.zip file, you will see that the creation of a branch is followed by a commit (a checking of all files from the original branch.
The space used is minimized, as described in Isolation for Collaboration page:

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

When you create a new branch and commit, all of the files in the new branch that are identical to the files in the source branch point to the same content.
The result is that a branch consumes very little additional storage space, and that storage space expands only when the branched file becomes different than the source.
And even when files change, Team Foundation Server employs a differencing engine to analyze changes between files and once again optimize storage space.

所以它是 TFS2008 的重分支(空间优化).

So it is heavy branching for TFS2008 (with space optimization).

在 TFS2010 中，分支是一流的对象，很容易与简单的文件夹分开.

In TFS2010, branches are first class object and easily separated from simple folders.

这篇关于Team Foundation Server 分支特性，与其他特性相比的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！