【问题标题】:TFS 2010 Branch Across Team Projects - Best PracticesTFS 2010 跨团队项目分支 - 最佳实践
【发布时间】:2011-08-08 21:42:59
【问题描述】:

我在理解如何根据 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 分支到 /Development,而是单独分支每个项目。 (不是团队项目...解决方案项目。)

这是由于无法嵌套分支根。 (请参阅 TFS 错误:TF203028 and TF203071

根据 TFS Ranger Guide 和我们修订后的版本、修补程序、开发分支方法,我们应该从 /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 正确设置项目,则永远不需要执行毫无根据的合并。

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

我也愿意接受其他解决方案。

谢谢!

【问题讨论】:

  • 这个问题的答案似乎是主观的。 Microsoft TFS Ranger 团队没有提供关于此主题的足够信息或解释。我很难奖励赏金,更不用说选择“正确”的答案了,所以我最终只会根据最多的投票来这样做。似乎提供的两种解决方案都可以正常工作,不使用 baseless-merge 的唯一原因只是因为 MS 说它不合适......其背后的原因似乎是未知的。

标签: tfs shared-libraries branching-and-merging


【解决方案1】:

我会给你一个选项,它可能对你有用,也可能没用。如果有什么安慰的话,我一直在思考这个问题,但还没有找到一个完全令人满意的解决方案。这是一个非常好的问题,我很想看看其他人是如何解决这个问题的。

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

因此,考虑到这一点,我建议您以与处理 3rd 方库并使用二进制引用相同的方式处理公共代码。一旦你进入这种心态,你就有很多选择。 (这里有一些,但可能还有更多)

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

正如我所说,我很想听听其他 SOer 如何使用 TFS 解决共享代码问题。

编辑:经过 8 年的思考,Nuget 包是前进的方向。我已将其余答案留在原处,因为它仍然获得意见和投票。将依赖项构建到包中并将它们存储在二进制存储库中(nuget / Nexus / Artifactory / Azure Artifacts 等)几乎是解决此问题的标准方法

【讨论】:

  • 这绝对是一种可能。但是,这里的主要缺点是 Product1 和 Product2 不能再维护自己的 Core 版本。 Core 的任何构建都必须与具有文件引用的每个项目兼容。我们只有 3-4 个团队项目,因此这可能是可以管理的,尽管这些团队项目有 12-16 范围内的解决方案项目,可能必须引用 Core。您对使用文件引用与无根据合并有何看法?再次感谢。
  • 我想我原则上反对毫无根据的合并,MS 建议不要这样做,我认为他们知道他们在做什么 :-) 我过去使用过它们,但只是作为最后的手段.我知道MS在TFS 2010 sp1中改进了它们我想我不明白的一件事是为什么从“核心”分支时毫无根据的合并不起作用?当您进行无根据合并时,它会建立合并关系,即后续合并不是无根据的,因此最终结果将是相同的
  • 非常感谢您的意见,James,这些信息肯定会有助于决定采取哪条路径。
  • 在我的团队中,我们将常用功能打包到 NuGet 包中。我们发现它工作得很好。将您自己的公共库视为第 3 方依赖项会迫使您编写更多可重用的代码;)
  • 使用 Nuget 管理通用代码对我们来说也很有效。
【解决方案2】:

重新审视 TFS 2010 分支:

我想为 TFS 2010 baseless 合并功能提供一种信心模式,作为解决此问题的一种方式。我强烈推荐阅读 Wrox 书籍“Professional Team Foundation Server 2010”。

在其中,它深入描述了这个问题,虽然它不提倡使用无根据的合并,但它阐明了如何在这样的场景中使用它们。

自从这个问题在 4 月首次解决以来,我们一直在使用它们,并且还没有遇到过毫无根据的合并出现问题的情况。我想根据本书和 ALM Ranger 团队的建议发布一张详细说明我们的分支设置的图片。

【讨论】:

    【解决方案3】:

    为了实现你想要的,你需要先将根目录下的所有分支都转换为文件夹,然后你就可以将根目录转换为文件夹了。

    我们一直坚持在不同的分支下合并,然后我们进行了毫无根据的合并。花了一些时间才弄清楚它是如何工作的,但后来我们成功地进行了跨分支合并,然后创建了它们之间的关系。

    tf merge /baseless "D:\TFS2010\Root\ServicePack" "D:\TFS2010\Root\MainLine" /recursive
    

    完成无根据合并后,您需要签入所有文件。还是会发现分支之间的关系没有建立。

    为此,单击 ServicePack 分支(根据我的示例),然后从文件菜单中单击源代码管理 -> 分支和合并 -> 重新父项。在那里,您可以选择重新养育子女。完成后,只要您想跨这些分支进行合并,您就可以像跨分​​支的正常合并一样进行操作。

    【讨论】:

    • 您能否对这样做可能产生的任何可预见的障碍发表评论?为什么微软吹捧使用毫无根据的合并作为最后的手段/“你不应该需要这个”功能。
    • 毫无根据的合并是我想说的好功能。这是我们针对基本面使用的功能之一。这是一个独特的命令,它允许我们跨不存在关系的分支进行合并。大约 6 个月前,我为我的公司使用了 baseless 合并,我们还没有遇到任何问题。即使不存在任何关系,我们也可以在分支之间创建关系,这是一个福音。我建议你继续进行毫无根据的合并。
    • 感谢您的意见 Sunil。我自己和项目经理很可能会测试这个毫无根据的功能并做出决定。
    【解决方案4】:

    我刚才一直在配置 TFS,遇到了同样的问题。 关键是,没有必要进行毫无根据的合并。 解决方法:

    1. 创建父分支

      $/Core/Main

    2. 创建子分支

      $/Product1
      -> /主要
      -> /主要/核心
      -> /Main/...

    3. 删除子分支文件夹

      $/Product1/Main/Core

    4. 使用 SAME 名称创建文件夹

      $/Product1/Main/Core

    5. 将 Product1 文件夹转换为分支

      $/Product1/Main

    现在您可以合并从 $/Core/Main$/Product1/Main/Core 的更改并向后合并。
    可视化不适用于 Core 分支,但我猜没关系;)

    【讨论】:

    • 好的,你可以convert branch back to folder,而不是删除文件夹,但是我没有出现这个选项。
    • 我知道这是旧的,但是您需要在源代码管理资源管理器中选择分支,然后单击文件(从主菜单)-> 源代码管理-> 分支和合并-> 转换为文件夹。此选项在上下文菜单中不可用。
    【解决方案5】:

    如果你想共享公共代码,那么你可以尝试以下解决方案:

    转到文件->源代码管理->从源代码管理添加项目...

    这将弹出一个对话框,允许您从源代码管理的其他位置添加项目。

    一旦您开始分享这样的项目,就值得在您的源代码控制结构中变得更健壮。

    我注意到的一件事是,如果您对公共代码进行更改,那么它将不会被自动检出。所以它有点类似于引用项目的不同之处在于它也适用于 TFS。

    answer

    【讨论】:

      猜你喜欢
      • 2011-10-15
      • 2011-11-26
      • 2012-12-04
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2012-02-16
      相关资源
      最近更新 更多