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

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

$/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。这正是我想要避免的，因为我不想破坏主分支。

所以，我想两个问题：

有没有办法让这个合并，而无需任何检查到主分支工作？
是否有更好的整体策略来处理这些类型的依赖关系，同时仍然保持它们在TFS中？（我知道TFS对于二进制文件不是“意味着”的，但我们喜欢它，因为我们从中获得了简单的多版本和历史跟踪）。

来源

2011-06-30 Michael Edenfield

对1的回答：
是的。您可以执行从ThirdParty到Working1的无基本合并。下面是MSDN页面：
http://msdn.microsoft.com/en-us/library/bb668976.aspx

至于2：如果你的项目主要可以使用2+不同版本的第三方二进制的，那么我建议储存第三方二进制文件的不同版本在$ /第三方区域，并且没有第三方区域和主区域中的文件之间的直接链接。

来源

2011-06-30 20:00:55

最终，工作分支中的版本凹凸也会在主布谱中产生，而不是立即产生。如果我直接在Working1中进行无基础合并，那么此更改集想要在稍后再合并到Main中吗？而我们在TFS中保存二进制文件的原因是为了让所有项目都保持在同一版本的某些库上（特别是像log4net这样的强名称）。由于我们的核心库引用它，其他所有内容都必须使用相同的版本，否则我们必须执行运行时程序集绑定重定向。（这次SNK发生了变化，即使这样也行不通。） –

是的。在向Working1进行无基本合并之后，可以将Working1合并到Main或从ThirdParty合并到main中（或者两者兼而有之，并且TFS应该知道二进制文件是相同的）。我们强迫我们发布的所有应用程序使用相同版本的第三方dll，而且我还没有处理强名称的第三方dll，所以我会记住你的方式，因为我的下一个第三方dll会强名。 –

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

来源

2011-07-01 00:57:01

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

回答

相关问题