26

我在理解如何根据 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 和 TF203071）

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

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

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

谢谢！

4

5 回答 5

15

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

我知道尽可能从源代码构建被认为是一个好主意，但我不喜欢在团队项目之间进行分支。如果您有一些通用代码并且需要在 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 等）几乎是解决此问题的标准方法

于 2011-04-22T00:39:57.050 回答
6

重新审视 TFS 2010 分支：

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

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

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

在此处输入图像描述

于 2011-06-22T18:45:18.667 回答
2

为了实现您想要的，您需要首先将根目录下的所有分支转换为文件夹，然后您才能将根目录转换为文件夹。

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

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

完成无根据的合并后，您需要签入所有文件。你仍然会发现分支之间的关系没有被创建。

为此，单击 ServicePack 分支（根据我的示例），然后从文件菜单中单击源代码控制 -> 分支和合并 -> 重新父级。在那里，您可以选择重新养育子女。完成后，无论何时您想要跨这些分支合并，您都可以像跨分​​支的正常合并一样进行操作。 在此处输入图像描述

于 2011-04-22T11:16:39.043 回答
1

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

  1. 创建父分支

    $/核心/主要

  2. 创建子分支

    $/Product1
    -> /Main
    -> /Main/Core
    -> /Main/...

  3. 删除子分支文件夹

    $/Product1/主要/核心

  4. 创建具有相同名称 的文件夹

    $/Product1/主要/核心

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

    $/Product1/主要

现在您可以合并从$/Core/Main到$/Product1/Main/Core和向后的更改。
可视化不适用于核心分支，但我猜没关系；）

于 2011-12-26T13:57:51.527 回答
0

如果您想共享公共代码，那么您可以尝试以下解决方案：

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

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

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

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

原始答案

于 2019-03-20T12:38:45.347 回答