我遇到了根据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/...
因此,我们有一个团队集合,并说这个例子有三个团队项目。 ($ / *是一个团队项目)
我们的初始版本分支有点痛苦。我们不是分支/ Main到/ Releases,或/ Main to / Development,而是分别对每个项目进行分支。 (不是团队项目......解决方案项目。)
这是由于无法嵌套分支根。 (参见TFS错误:TF203028 and 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)
解决方案: 1.我们可以将每个共享分支(即$ / Core)转换回常规文件夹。这样,/ Main下的文件夹就不是分支根目录。然后我们可以执行从$ / Product1 / Main / Source / Core / Source到父$ / Core / Source的无基础合并。
有没有任何基础合并的经验。我从微软那里读到的是,它们是不应该是司空见惯的例外。 MS指出,如果使用TFS正确设置项目,则永远不需要执行无基础合并。
跨团队项目分支时,这怎么可能?!?在任何软件开发公司中,在产品之间共享库应该是司空见惯的。
我也对其他解决方案持开放态度。
谢谢!
答案 0 :(得分:11)
我会向戒指投掷一个选项,它可能对您有用,也可能没用。如果有任何安慰,我一直在思考这个问题一段时间,而且还没有能够提出一个完全令人满意的解决方案。这是一个非常好的问题,我很想知道别人如何解决这个问题。
我知道尽可能从源代码构建是一个好主意,但我不喜欢团队项目之间的分支。如果你有一些共同的代码,并且它需要在2或3个其他团队项目之间进行分支,那么分支是可管理的,但如果你有20或30个(或100个)团队项目,那么管理合并变得令人头疼。如果在消费团队项目中工作的开发人员在“主”中没有相同的权限,例如无法查看历史记录等,则可能存在其他问题。当然,如果您需要在团队项目之间共享代码在不同的项目集合中,你无论如何都不能分支。
因此,考虑到这一点,我建议您使用与处理第三方库和使用二进制引用相同的方式处理公共代码。一旦您了解了这种心态,您就可以使用多种选项。 (这里有一些,但可能还有更多)
正如我所说,我非常有兴趣了解其他SOers如何使用TFS解决共享代码问题。
答案 1 :(得分:6)
重访TFS 2010分支:
我想为TFS 2010无基础合并功能提供一种信任模式,以此作为解决此问题的方法。我强烈建议您阅读Wrox一书“Professional Team Foundation Server 2010”。
在其中,它深入地描述了这个问题,虽然它并不提倡使用无基础的合并,但它揭示了如何在这样的场景中使用它们。
我们一直在使用它们,因为这个问题在4月份首次得到解决,并且还没有遇到无根据合并存在问题的情况。我想按照本书和ALM Ranger团队的建议发布一张详细说明我们分支设置的图片。
答案 2 :(得分:2)
为了达到你想要的效果,你需要先将root下的所有分支转换为文件夹,然后你就可以将root转换为文件夹了。
我们一直坚持在不同的分支下合并,然后我们进行了毫无根据的合并。花了一些时间来弄清楚它是如何工作的,但后来我们成功地进行了合并,然后创建了它们之间的关系。
tf merge /baseless "D:\TFS2010\Root\ServicePack" "D:\TFS2010\Root\MainLine" /recursive
完成baseless merge后,您需要签入所有文件。你仍然会发现分支之间的关系没有创建。
单击ServicePack分支(根据我的示例),然后从文件菜单中单击Source Control - >分支和合并 - >重新设置父级。在那里,您可以选择重新育儿。一旦完成,因此每当您想要跨这些分支合并时,您将能够像跨分支的正常合并一样。
答案 3 :(得分:1)
我刚刚配置TFS并遇到了同样的问题。 关键是,没有必要进行毫无根据的合并。 解决方法:
$ /核心/主要
创建子分支
$ /产品1
- > /主要
- > /主要/核心
- > /主/...
删除子分支文件夹
$ /产品1 /主/核心
$ /产品1 /主/核心
将Product1文件夹转换为分支
$ /产品1 /主要
现在您可以将 $ / Core / Main 中的更改合并到 $ / Product1 / Main / Core 并向后合并。
可视化对Core分支不起作用,但我猜是好的;)
答案 4 :(得分:0)
如果您要共享通用代码,则可以尝试以下解决方案:
转到文件->源代码管理->从源代码管理添加项目...
这将弹出一个对话框,允许您从源代码管理中的其他位置添加项目。
一旦您开始共享这样的项目,就值得在源代码控制结构中增强一点功能。
我注意到的一件事是,如果您对通用代码进行更改,那么它将不会被自动检出。因此,引用项目差异有点类似于它也可以在TFS中使用。
原始answer