svn - TFS文件夹-使它们像Subversion“Trunk/Tags/Branches”一样工作

Question

我最近开始使用Team Foundation Server，但在使其按我希望的方式工作时遇到了一些麻烦。

我已经使用Subversion几年了，并且喜欢它的工作方式。我总是在每个项目，主干，标签和分支下设置三个文件夹。

在处理项目时，我所有的代码都位于一个名为“ C：\ dev \ projectname”的文件夹下。使用Subversion（使用switch命令），可以使此“ projectname”文件夹指向中继线或任何分支或标记。

现在，我正在使用TFS（客户端系统），我希望事情以相同的方式工作。我创建了一个包含项目的“ Trunk”文件夹，并将“ Project / Trunk / Website”映射到“ c：\ dev \ Website”。

现在，我想在“ tags”文件夹（位于“ Project / Tags / Version 1.0 / Website”下）下进行发布，并且当我执行branch命令时，TFS给我以下错误：

“ $ Project / tags /版本1.0 /网站不存在适当的映射”

根据我在互联网上可以找到的信息，TFS希望您在项目的根目录（本例中为“ Project”文件夹）中具有到硬盘驱动器的映射，然后将所有源代码保存在主干中，标记和所有分支都下拉到您的硬盘驱动器。这很烂，因为它在硬盘驱动器上需要太多的东西，更糟糕的是，当您在Visual Studio中的解决方案中工作时，您将无法下拉“版本2.0”并将所有项目引用都指向其他版本项目之所以有效，是因为它们都指向主文件夹下的“ trunk”文件夹，而不仅仅是主文件夹本身。

我想做的是在我的硬盘驱动器上有根“ Project / Website”文件夹，并且能够根据我在做什么而使其指向（映射到）标签，分支或主干，而无需修复Visual Studio项目引用。

有想法吗？

Answer 1

首先要了解的是，版本树的TFS模型与您可能习惯的模型不同。它处于光谱的最末端。‡


我已经使用Subversion几年了，并且喜欢它的工作方式。我总是在每个项目，主干，标签和分支下设置三个文件夹。


您认为的“标签，分支和主干”都由TFS中的文件夹表示。 “ trunk”是通过简单添加创建的文件夹，而不是作为另一个文件夹的分支而创建的。 “分支”是通过“分支和合并”操作从系统其他位置的另一个文件夹派生（并与之相关）的文件夹。 TFS本身没有“标签”。最接近的模拟是基于历史版本（通过变更集编号或标签）创建分支。再次，它成为另一个文件夹。

在管理本地工作区时，“一切都在文件夹中”这一概念是个好消息。如果要在标签/分支/主干上创建任意复杂的视图，则在TFS世界中，该任务可以简化为映射本地路径<->服务器路径的非常简单的问题。

当然，这并不意味着您应该这样做。磁盘空间比网络带宽或服务器CPU周期便宜很多。更重要的是：映射越复杂，就越有可能将错误的文件意外提交到错误的位置。我通常的建议是：


为您正在积极工作的每个分支/标记创建一个工作区。
在每个工作空间中，仅创建一个到分支根的递归映射。


如果由于树枝的大小而无法这样做，请避免穿披风。它们不是一个很好的解决方案，因为它们不会与其他人添加的文件夹/重命名保持同步。最好使用到分支根目录的一级映射+到您需要的文件夹的其他递归映射。
如果由于分支中未包含构建时依赖性而无法执行此操作，请感到羞耻：)将最少数量的其他映射添加到公共库中。

确保每个分支内的相对路径相同。 （如果它们发生更改，结构的更改将与您的makefile的更改同步地传播。）
为我称为“维护”任务的内容创建一个额外的工作区。


该策略提供：


资源开销为零。上下文切换时无需重新下载。
精神开销低。要开始在另一个分支上工作，只需从磁盘打开解决方案的另一个副本。或更改“源代码管理资源管理器”中的“工作区”下拉列表。
搞砸的机会很小。因为分支仅限于自己的工作区，所以单击“全部签入”将永远不会提交另一个分支中待处理的更改……或更糟糕的是，您不能无意间对旨在防止“不稳定”的“发布”分支进行更改”版本。



我想做的是在我的硬盘驱动器上有根“ Project / Website”文件夹，并且能够根据我在做什么而使其指向（映射到）标签，分支或主干，而无需修复Visual Studio项目引用。


这也是可能的。如前所述，您只是在为磁盘带宽/ CPU交换磁盘空间。如果您的基础架构支持，那没什么大不了的。我个人会发现它在并行开发方面过于局限，而且更有可能发生搞砸的情况，但这是自然而然的事实，一个在SVN上成长的人可能会有不同的感觉。

步骤如下：


创建一个工作区。将其映射到下一步要使用的分支/标签/主干。
请遵循上述所有其他准则。
当需要更改分支/标签/主干时，请重新打开“工作区”对话框，并将相同的本地文件夹指向新的服务器路径。
获取最新消息。


从TFS 2008开始，客户端在进行这样的更改时将自动提示您运行“获取”。
从TFS 2008 SP1开始，还有一种更好的方法。在提示上单击“否”，然后运行tf get / remap。这只会下载两个分支之间的差异。这可能会节省大量带宽/ CPU，具体取决于文件夹的大小以及它们之间的关联程度。 （实际上，在很小，非常相关或完全不相关的文件夹上可能会占用更多服务器CPU；请使用良好的判断力。尽管如此，它始终严格占用较少的带宽。）





‡在TFS中，当您创建分支时，它在用户看来是全新的文件夹层次结构。换句话说，当您先看存储库时，没有明确的方法可以将“真实”文件/文件夹与分支区分开。坦白说，两者之间并没有太大的区别。 “分支”只是另一项，恰好具有与之关联的> = 1条合并历史记录元数据。很多TFS命令都依赖于上述元数据，您当然可以直接查询它，但是它不会显示在简单的tf目录中。同时，由于每个分支在path space中都占据唯一的位置，这意味着唯一地指定分支的versionspec并不复杂。 $ / path; changeset就足够了，就像其他任何项目一样。

CVS采用相反的方法。分支时，路径不会改变。相反，您要做的是沿另一个维度对版本进行分叉。这使得简单的案例非常容易可视化：只有一棵树。当然，您仅将复杂性转移到其他地方。当您要唯一地指定项目的版本时，仅知道路径和修订号已不再足够。您也需要知道分支。而且，如果您在一个分支而不是另一个分支中重命名文件怎么办？在TFS中，直到合并分支之前，没人会关心。在CVS中，仅查看存储库会引发问题。我敢肯定，您还能想到其他微妙之处-我对它还不够熟悉，无法知道它如何处理每种极端情况。

大多数SCC系统介于这些极端之间。让我们将TFS 2005/2008称为最左端，将CVS称为相对的“右端”。

Subversion基本位于TFS的“左”极。尽管实现方式有很大不同，但由于最终实现了合并跟踪，因此用户对分支的看法几乎相同。 （有人可能会说，在v1.5之前，它离TFS甚至还差一点。分支只是具有低级优化的副本；用户无法查询关系元数据。SourceSafe属于同一类别，如果由于缺少系统范围的版本号而走得更远。）来自SVN世界的用户一旦了解了客户端/服务器工作区模型并重新定义了术语，就不会感到困难。 （SVN在术语上有很多CVS包，例如单词“ tag”；为了公平起见，TFS继承了VSS的一些口头表达，例如，尽管默认情况下被“编辑-合并-提交”，但仍普遍使用“ checkin / checkout”。）

Perforce是TFS右侧的一个级别。它们的基本模型是相同的。它们具有分支规范的其他概念，可以满足一些常见的用户场景-例如，快速了解“哪些文件夹代表分支”，指定不需要完整路径的分支版本规范的快捷方式-但这仅仅是语法糖。

TFS 2010在右边还有两个标记。像Perforce一样，他们创建了一个“分支对象”存储，它们独立于（但映射回）存储库树而存在。每个分支还知道用户定义的分支层次结构内的关系（例如，父，子，无基础）。

我会将ClearCase放置在右侧约2/3的位置。从服务器的角度来看，复杂的分支方案基本上发生在版本空间中。但是，它们具有极为强大的“视图”系统，位于其顶部。结果，用户实际看到的结构可能被操纵为类似于路径空间或某种混合形式。相似级别的可定制性适用于其本地工作空间映射。

大多数其他“企业” SCM大约在右侧的3/4处。 （例如AccuRev，MKS，StarTeam），用户通常可以以多种强大的方式查看资源库+分支树，但无法像CC一样灵活地配置系统本身。这可能是一件好事:)

如前所述，CVS位于最右边。同上它的祖先RCS和SCCS。

对诸如Monotone，BitKeeper及其派生类之类的分布式系统进行分类超出了此答案的范围:)



§完全不需要工作空间即可完成TFS中的几个较新的操作：


创建分支（tf分支/签入-需要2008 SP1）
销毁物品（需要2008年）


其他一些要求映射到工作空间，但不需要下载任何文件：


删除项目
锁定物品
按旧方式创建分支（tf分支/ noget-自2005早期测试版开始可用）


还有一些需要部分映射和/或部分下载：


合并仅需要映射和下载目标路径。
重命名需要同时映射路径和要下载的目标。
取消删除/ newname的工作类似于重命名。


我更喜欢在自己的“维护”工作区中进行此类操作，与我的日常开发隔离。拥有自己的工作区也意味着我可以一口气映射存储库的大部分，而无需实际下载它们。 （相反，在您的“开发”工作区中，最佳做法是运行Get w / o任何限制性路径范围。）正如我已经提到过几次，现在保持本地<->服务器映射相对简单且相对路径保持不变，引用不会中断，文件不会意外提交或提交到错误的位置；每个人通常都比较快乐。

YMMV。