TFS 2010跨团队项目分支 - 最佳实践

Dan*_*iel 25 tfs shared-libraries tfs2010 branching-and-merging

我在根据TFS Ranger团队提供的最佳实践了解如何配置TFS时遇到了问题.问题是这样的:

我公司有几种产品可以使用共享的公共代码库.

> $/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/...
Run Code Online (Sandbox Code Playgroud)

因此,我们有一个团队集合,并说这个例子有三个团队项目.($/*是一个团队项目)

我们的初始版本分支有点痛苦.我们不是分支/ Main到/ Releases,或/ Main to/Development,而是分别对每个项目进行分支.(不是团队项目......解决方案项目.)

这是由于无法嵌套分支根.(参见TFS错误:TF203028和TF203071)

根据TFS游侠指南和我们修订的分支发布,修补程序,开发方法,我们应该从/ Main而不是/ Main/Source/Proj1,/ Proj2,/ Proj3等分支.这只是一个相当大的烦恼.

理想情况下,我们希望:

> $/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)
Run Code Online (Sandbox Code Playgroud)

解决方案:1.我们可以将每个共享分支(即$/Core)转换回常规文件夹.这样,/ Main下的文件夹就不是分支根目录.然后我们可以执行从$/Product1/Main/Source/Core/Source到父$/Core/Source的无基础合并.

有没有任何基础合并的经验.我从微软那里读到的是,它们是不应该是司空见惯的例外.MS指出,如果使用TFS正确设置项目,则永远不需要执行无基础合并.

在跨团队项目分支时,这怎么可能?!?在任何软件开发公司中,在产品之间共享库应该是司空见惯的.

我也对其他解决方案持开放态度.

谢谢!

Jam*_*eed 13

我会向戒指扔一个选项,它可能对您有用,也可能没用.如果有任何安慰,我一直在思考这个问题一段时间,而且还没有能够提出一个完全令人满意的解决方案.这是一个非常好的问题,我很想知道别人如何解决这个问题.

我知道尽可能从源代码构建是一个好主意,但我不喜欢团队项目之间的分支.如果你有一些共同的代码,并且需要在2或3个其他团队项目之间进行分支,那么分支是可管理的,但如果你有20或30个(或100个)团队项目,那么管理合并变得令人头疼.如果在消费团队项目中工作的开发人员在"主"中没有相同的权限,例如无法查看历史记录等,则可能存在其他问题.当然,如果您需要在团队项目之间共享代码在不同的项目集合中,你无论如何都不能分支.

因此,考虑到这一点,我建议您以与处理第三方库和使用二进制引用相同的方式处理公共代码.一旦您了解了这种心态,您就可以使用多种选项.(这里有一些,但可能更多)

  1. 您可以使用公共代码的构建将二进制文件复制到放置位置,以及用于打包的合并模块(如果使用MSI).然后,您可以创建对放置位置的二进制引用,并获取用于打包的任何内容以导入合并模块.在这种情况下,您需要确保丢弃位置稳定(并且最好只读取大多数开发人员以防止篡改)
  2. 与选项1类似,但使用像NuGet这样的工具来管理引用,这将自动引用新版本的二进制文件.如果您想要更多地控制新版本的推出,这可能不是一个选项.
  3. 您可以在分支中检入分支中的$/Product1/branch/lib/common文件夹,并使用相对路径引用它们

正如我所说的,我非常有兴趣了解其他SOers如何使用TFS解决共享代码问题.

  • 在我们的团队中,我们将常用功能打包到NuGet包中。我们发现它运作良好。将您自己的公共库当作第三方依赖项会迫使您编写更多可重用的代码;) (2认同)

Dan*_*iel 6

TFS 2010分支重访:

我想为TFS 2010 baseless merge功能提供一种信任模式,作为解决此问题的一种方法.我强烈建议您阅读Wrox一书"Professional Team Foundation Server 2010".

在其中,它深入描述了这个问题,虽然它并不提倡使用无基础的合并,但它揭示了如何在这样的场景中使用它们.

我们一直在使用它们,因为这个问题在4月份首次得到解决,并且还没有遇到无根据合并存在问题的情况.我想按照本书和ALM Ranger团队的建议发布一张详细说明我们分支设置的图像.

在此输入图像描述


归档时间:

查看次数:

12390 次

最近记录:

7 年 前