TFS 2010跨团队项目的分支-最佳实践 [英] TFS 2010 Branch Across Team Projects - Best Practices
问题描述
我在理解如何根据TFS Ranger团队提供的最佳实践配置TFS时遇到问题。问题是这样的：
I'm having issues understanding how to configure TFS according to best practices as provided by the TFS Ranger team. The issue is such:
我的公司有几种产品使用共享的通用代码库。
My company has several products which make use of a shared common code base.
> $/Core
> -> /Main/Source (Parent Branch)
>
> $/Product1
> -> /Main/Source
> -> /Main/Source/Core/Source (Child Branch from $/Core)
> -> /Main/Source/...
>
> $/Product2
> -> /Main/Source
> -> /Main/Source/Core/Source (Child Branch from $/Core)
> -> /Main/Source/...
因此，我们有一个团队集合，说，三个团队项目这个例子。 （$ / *是一个团队项目）
Therefore we have one team collection and say, three team projects for this example. ($/* is a team project)
我们最初的发行分支有些痛苦。我们没有将/ Main分支到/ Releases，或将/ Main分支到/ Development，而是将每个项目分别分支。 （不是团队项目...解决方案项目。）
Our initial release branching is a bit of a pain. Instead of branching on the /Main to /Releases, or /Main to /Development, we have been branching each project individually. (Not team project ... solution project.)
这是因为无法嵌套分支根。 （请参见TFS错误： TF203028和TF203071 ）
This is due to the inability to have nested branch roots. (See TFS Errors: TF203028 and TF203071)
根据《 TFS游侠指南》和我们对分支发行版，修补程序，开发的修订方法，我们应该从/ Main而不是/ Main / Source / Proj1，/ Proj2，/ Proj3等分支。
According to TFS Ranger Guide and our revised approach to branching releases, hotfixes, developments, we should branch from /Main rather than /Main/Source/Proj1,/Proj2,/Proj3, etc. It's just become a rather large annoyance.
理想情况下，我们希望：
Ideally we would like:
> $/Product1
> -> /Main/ (Branch - Parent)
> -> /Releases
> -> /1.x
> /1 Service Pack (Child Branch from $/Product1/Main
> -> /1.0
> -> /1.0 Hotfix (Child Branch from $/Product1/Releases/1.x/1 Service Pack)
> -> /1.0 RTM (Child Branch from $/Product1/Releases/1.x/1.0/1.0 Hotfix - Read Only)
> -> /1.0.22 RTM (Child Branch from $/Product1/Releases/1.x/1.0/1.0 Hotfix - Read Only)
> -> /1.5
> -> /1.5 Hotfix (Child Branch from $/Product1/Releases/1.x/1 Service Pack)
> -> /1.5 RTM (Child Branch from $/Product1/Releases/1.x/1.5/1.5 Hotfix - Read Only)
解决方案：
1.我们可以将每个共享分支（即$ / Core）转换回去到常规文件夹。这样，/ Main下的文件夹都不是分支根目录。然后，我们可以从$ / Product1 / Main / Source / Core / Source回到父$ / Core / Source进行无基础的合并。
Solutions: 1. We can convert each shared branch (ie. $/Core) back to regular folders. This way no folder under /Main is a branch root. We can then perform a baseless merge from $/Product1/Main/Source/Core/Source back to the parent $/Core/Source.
任何人都可以进行无基础的合并，我从Microsoft那里读到的是它们是例外，不应该很普遍。 MS指出，如果使用TFS正确设置项目，则永远不需要执行无基础的合并。
Has anyone any experience with baseless merges. What I've read from Microsoft is that they are exceptions which should not be commonplace. MS states that if you set up your projects properly with TFS, you would never need to perform a baseless merge.
跨团队项目进行分支时，这怎么可能？！？在任何软件开发公司中，在产品之间拥有共享库应该是司空见惯的。
How is this possible when branching across team projects?!? It should be commonplace in any software development house to have shared libraries amongst products.
我也对其他解决方案持开放态度。
I'm open to other solutions too.
谢谢！
推荐答案
我会在环上扔一个选项，它可能会也可能不会对您有用。如果有什么安慰的话，我已经考虑了好一阵子了，还没有一个完全令人满意的解决方案。这是一个非常好的问题，我很想看看其他人如何解决了这个问题。
I'll throw an option in to the ring, it may or may not not be useful to you. If it's any consolation I've been pondering over this one for a while now and haven't been able to come up with a completely satisfactory solution. It's a really good question and I'd be very interested in seeing how others have solved this problem.
我知道尽可能从源代码构建是个好主意，但我不喜欢在团队项目之间进行分支。如果您有一些通用代码，并且需要在其他2个或3个其他Team Project之间进行分支，那么该分支是可管理的，但是如果您有20个或30个（或100个）Team Projects，那么管理合并就变得很头疼。如果在使用中的团队项目中工作的开发人员在主中没有相同的权限，则可能会出现其他问题，例如无法查看历史记录等。当然，如果您有需要在团队项目之间共享的代码
I know it's considered a good idea to build from source wherever possible but I'm not a fan of branching between Team Projects. If you have a some common code and it needs to be branched between 2 or 3 other Team Projects then the branching is manageable but if you have 20 or 30 (or 100) Team Projects then managing the merges becomes a headache. There can be other issues if the developers working in the consuming Team Projects don't have the same permissions in the "master" such as not being able to see history etc. Of course if you have code that needs to be shared between Team Projects in different Project Collections then you can't branch anyway.
因此，考虑到这一点，我建议您以与对待第三个代码相同的方式对待通用代码方库并使用二进制引用。进入该思维定式后，您可以使用许多选项。 （这里有一些，但可能还有更多）
So with that in mind I would suggest that you treat the common code in the same way you might treat a 3rd party library and use binary references. Once you get in to that mindset a number of options are available to you. (here are a few but there are probably more)
- 您可以让通用代码的构建文件将二进制文件复制到放置位置，以及用于打包的合并模块（如果使用MSI）。然后，创建对放置位置的二进制引用，并获取用于打包以导入合并模块的所有内容。在这种情况下，您需要确保放置位置稳定（最好对大多数开发人员只读，以防止篡改）
- 与选项1类似，但使用 NuGet 来管理您的引用，这将自动引用新版本的二进制文件。
- 您只需将二进制文件检入分支中$ / Product1 / branch / lib / common文件夹，然后使用相对路径引用它们即可。
- You could have the build for your common code copy the binaries to a drop location, alongside a merge module for packaging (if you use MSI). You then create a binary reference to the drop location and get whatever you use for packaging to import the merge module. In this scenario you need to make sure that the drop location is stable (and preferably read only to most of the devs to prevent tampering)
- Similar to option 1 but use a tool like NuGet to manage your references, this will automate the process of referencing new versions of the binaries.
- You could just check in the binaries to $/Product1/branch/lib/common folder in your branch and reference them using a relative path
正如我所说，我对听到其他SOers如何使用TFS解决共享代码问题非常感兴趣。
As I said, I'm very interested in hearing how other SOers have solved the shared code problem using TFS.
编辑：经过8年的思考，Nuget软件包是这里的前进之路。我将剩下的答案留在原地，因为它仍然可以得到观看和投票。在软件包中建立依赖关系并将其存储在二进制存储库（nuget / Nexus / Artifactory / Azure Artifacts等）中，几乎是解决此问题的标准方法
After 8 years of thinking about this, Nuget packages are the way forward here. I've left the rest of the answer in place as it still gets views and up-votes. Building dependencies in to packages and storing them in a binary repository (nuget / Nexus / Artifactory / Azure Artifacts etc.) is pretty much the standard way of solving this problem
这篇关于TFS 2010跨团队项目的分支-最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
