如何最好地在 Clearcase 中建立分支？答案

【问题标题】：How best to branch in Clearcase?如何最好地在 Clearcase 中建立分支？
【发布时间】：2009-06-15 13:58:34
【问题描述】：

我之前documented 我对 Clearcase 作为源代码控制系统的看法，但不幸的是我仍在使用它。所以我求助于你们来帮助我减轻我的挫败感。

我们刚刚从每个开发人员一个分支系统转变为每个任务一个分支系统，以尝试改善我们在确定某些文件更改的原因时遇到的一些问题。一般来说，我对解决方案感到满意，但有一个主要问题。我们使用简单的脚本来启动和结束任务，这些任务创建一个以用户名和任务编号命名的新分支，然后更新本地快照视图以具有类似于以下的配置规范：

元素 * 结帐元素 * .../martin_2322/LATEST 元素 * /main/LATEST -mkbranch martin_2322 加载/项目/应用程序

假设我的项目有两个耦合文件 A.cs 和 B.cs。对于我的第一个任务，我在分支上对 A 进行了更改。然后无论出于何种原因，我都需要停止处理任务 2322 并开始处理任务 2345（任务 2322 尚未完成，所以我不会将其合并回主任务）。我创建了一个新的任务分支 2345，编辑 A.cs 和 B.cs 并将结果合并回 main。现在我回到 2322 上工作，所以我将我的配置规范改回上面定义的配置规范。此时，我看到了来自任务分支的 A.cs 文件（因为我之前编辑过它，所以我得到了该分支的本地版本）和来自 main 的 B.cs 的最新版本。由于我没有对 2345 分支上的 A.cs 进行更改，因此构建中断。相反，我需要的是能够从我离开的地方拿起任务 2322，并使用旧版本的 A.cs 来查看它 - 这是创建分支时 main 中最新的版本。

在我看来，我有几个选项可以解决这个问题：

更改配置规范，使其在正确的日期从 main 获取文件。如果我知道日期并且不介意手动设置它，这很容易做到，但我不知道如何将它自动化到我们的任务切换脚本中。有没有办法获取分支的创建日期？
为 main 上的每个分支创建一个标签。理论上做起来很简单，但是我们安装的 CC 中的标签系统已经在几百个标签的重压下崩溃了，所以我不知道它是否可以处理每个分支的每个开发人员（请注意我的示例中的任务是 2322，我们只完成了项目的四分之一）
从主分支合并到任务分支。再次应该可以工作，但是长时间运行的分支将不仅包含为该任务更改的文件，还包含所有需要合并以使不相关的事情正常工作的文件。这使得它们与每个开发人员的分支方法一样复杂。我想查看为完成特定任务而更改了哪些文件。

我希望我只是在这里遗漏了一些东西，并且有一种方法可以设置我的配置规范，以便它从 main 检索预期的文件，而无需笨拙的解决方法。那么，你们在 Clearcase 中的分支情况如何？

【问题讨论】：

刚刚添加了另一个更容易 (IMO) 管理分支之间切换的解决方案。
刚刚添加了关于“新文件”选择规则的评论。在继续您当前的配置规范之前，一定要仔细检查和理解。

标签： clearcase

【解决方案1】：

几个cmets：

每个任务的分支是修改“工作单元”内的一组文件的正确粒度。前提是“任务”不是太窄，否则你最终会得到一大堆分支（及其相关的合并）
当您为分支创建配置规范时，您显然忘记了 new 元素的行（您“添加到源代码管理”的元素）
另外，您可以考虑为修复起点进行分支，这将解决“A.cs 的旧版本 - 创建分支时 main 中最新的版本”位。
我知道你已经有太多标签了，但你可以有一个脚本来“关闭”一个任务，该任务将（除其他外）删除该起始标签，避免标签混乱。

这里是我要使用的配置规范：

element * CHECKEDOUT 
element * .../martin_2322/LATEST  
element * STARTING_LABEL_2322 -mkbranch martin_2322 
# selection rule for new "added to source control" file
element * /main/0 -mkbranch martin_2322 
load /Project/Application

我会发现这比计算分支日期要容易得多。

不要忘记您可以将任务合并回主任务，和如果您需要改进一些修复，也可以将完成任务分支中的一些文件合并到新的当前任务分支也回到当前的任务。

【讨论】：

感谢 cmets，我的配置规范和添加新文件没有遇到任何问题，但我会再看一下。我同意标签是最好的方法，但是在服务器上做任何有足迹的事情都会有各种后勤问题，所以现在这不是一个真正的选择。很高兴知道我走在正确的道路上，并且没有错过“让任务分支按照我想要的方式工作”——这是我的主要恐惧。
> 我的配置规范和添加新文件没有遇到任何问题。嗯...我确实会调查一下：使用您当前的配置规范，一个新文件将在主分支中直接可见！（没有隔离）。如果该新文件随后被修改，它将位于任务分支中。我建议直接在任务分支中创建一个新文件，仅在需要时将其合并回主分支。

【解决方案2】：

您可以使用 cleartool 中的 describe 命令获取分支的创建日期。

cleartool describe -fmt "%d" -type martin_2322

这将打印出创建分支的日期和时间。您可以使用它来实现您的第一个选项。有关更多信息，您可以阅读以下 cleartool 手册页，但希望上述命令就是您所需要的。

cleartool man describe

cleartool man fmt_ccase

【讨论】：

完美，谢谢。我今天没有时间测试我的批量编写技能并修复我们的启动任务脚本，但至少我可以很容易地找到合适的时间手动更新配置规范。

【解决方案3】：

我们使用 Clearcase，我们发现为发布创建分支通常比按任务完成要容易得多。如果您确实按任务创建它，那么我将为该版本创建一个“主分支”，并将任务从该分支分支出来，然后在完成后将它们合并回主干。

【讨论】：

您对主分支/发布分支/任务分支/任务分支的建议正是我们正在做的，但这会导致上面列出的问题，即您无法真正并行处理两个任务。我们按开发人员进行分支，这意味着我们没有遇到这些问题，因为所有任务都在同一个分支中，但是由于 Clearcase 中没有“工作单元”概念，因此无法确定哪些更改属于哪个任务。
是的，你可以。创建两个视图，每个“任务”一个。然后，您可以使用 diff 工具以及将更改合并到从一个分支到另一个分支的端口更改的能力。
我觉得你在这里说的很有用，但我就是不明白。当您说视图时，您是指快照视图吗？我并不是真的希望将更改从一个分支合并到另一个分支，我正在寻找一个系统，其中合并到 main 中的更改不会显示在现有的分支中。
如果你去掉配置规范的行：element element * /main/LATEST -mkbranch martin_2322 那么你将不会自动获得对 main 的更改。