TFS 2010：如何处理工作分支的外部“分支”依赖关系

Question

在TFS工作分支中是否存在用于处理外部依赖关系的既定“最佳实践”？我的意思是，我们在TFS中有一个包含常见第三方库的项目（在这种情况下，我专门处理log4net），我们根据需要将其分支到其他项目中。现在，我们正在对一个单独的工作分支进行重大更改，这需要更新版本的组件。看起来基本上是这样的：

$/ThirdParty
  /bin
    /log4net

$/Product
  /Main
    /thirdparty
      /lognet      <-- $/ThirdParty/bin/log4net
  /Working1        <-- $/Product/Main
    /thirdparty
      /log4net     <-- $/Product/Main/lognet <-- $/ThirdParty/bin/log4net

部分工作需要针对.NET 4客户端配置文件重建log4net并引入新版本。通常，当我们升级第三方组件时，它会在相应的文件夹中检入$/Thirdparty，然后各个项目可以自由地合并最新的二进制文件，或者不合并。

据我所知，为了从$/ThirdParty/bin/log4net获取最新的变更集，我需要将其合并到$/Product/Main，检查合并到TFS ，然后将该分支合并到$/Product/Working1。这正是我想要避免的，因为我不想破坏主分支。

所以，我猜两个问题：

1. 有没有办法让这个合并无需检查主分支中的任何内容？

2. 是否有更好的整体策略来处理这些依赖关系，同时仍然将它们保留在TFS中？ （我知道TFS对于二进制文件并不“意味着”，但我们喜欢它，因为我们可以轻松实现多版本和历史跟踪）。

Answer 1

回答1：
是。你可以从ThirdParty到Working1进行毫无根据的合并。这是MSDN页面：
http://msdn.microsoft.com/en-us/library/bb668976.aspx

至于2： 如果您的主项目可以使用2个以上不同版本的第三方二进制文件，那么我建议在$ / ThirdParty区域中存储单独版本的第三方二进制文件，而不是在第三方区域和主要文件之间存在直接链接区域。

Answer 2

为什么不完全取消ThirdParty项目？只需将第三方库的所有版本保留在文件共享上，并根据需要在每个项目的树中检查相应的版本。