如何在Clearcase中最佳地进行分支？

Question

如何在Clearcase中最佳地进行分支？

3

我之前已经记录了我对Clearcase作为源代码控制系统的看法，但不幸的是我仍在使用它。所以我求助于你们帮我解决其中的一个问题。

我们刚刚从一个每个开发者一个分支的系统转换到了一个每个任务一个分支的系统，以改善我们在确定哪些文件被更改时遇到的一些问题。总体而言，我对这个解决方案感到满意，但有一个主要问题。我们使用简单的脚本来启动和结束任务，这些脚本会创建一个以用户名和任务编号命名的新分支，然后更新本地快照视图以具有类似以下内容的配置规范：

    element * CHECKEDOUT 
    element * .../martin_2322/LATEST  
    element * /main/LATEST -mkbranch martin_2322 
    load /Project/Application

假设我的项目有两个相互关联的文件A.cs和B.cs。对于我的第一个任务，我在分支上对A进行了更改。然后，由于某种原因，我需要停止2322任务的工作并开始2345任务的工作（2322任务未完成，因此我不会将其合并回主干）。我创建了一个新的任务分支2345，编辑了A.cs和B.cs，并将结果合并回主干。现在我回到2322任务，所以我将配置规范更改回上面定义的规范。此时，我看到来自任务分支的A.cs文件（因为我之前编辑过它，所以我得到该分支本地版本），以及来自主干的最新版本的B.cs。由于我没有在2345分支上对A.cs进行更改，因此构建失败。相反，我需要能够从离开时继续执行2322任务，并查看旧版本的A.cs-即在创建分支时在主干中最新的版本。

我认为我有几个修复选项：

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

我希望我只是漏掉了某些东西，有一种设置我的配置规范，以便从主分支检索预期文件而不使用笨拙的解决方法。那么，你们在Clearcase中是如何分支的呢？

- Martin Harris

刚刚添加了另一个更容易（在我看来）管理分支切换的解决方案。 - VonC

刚刚添加了关于“新文件”选择规则的注释。在继续使用当前配置规范之前，一定要仔细检查和理解这个规则。 - VonC

3个回答

2

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

cleartool describe -fmt "%d" -type martin_2322

这将打印出分支创建的日期和时间。您可以使用此来实现您的第一个选项。如需更多信息，您可以阅读以下cleartool手册页面，但希望上述命令已经满足您的需求。

cleartool man describe

cleartool man fmt_ccase

- A. Levy

太好了，谢谢。今天我没有时间测试我的批处理写作技能并修复我们的启动任务脚本，但至少我可以轻松找到合适的时间手动更新配置规范。 - Martin Harris

1

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

- George Stocker

你提出的主分支/发布分支/任务分支建议正是我们正在做的，但这会导致上述问题，即你不能真正并行地处理两个任务。我们按开发人员进行分支，这意味着我们没有遇到这些问题，因为所有的任务都在同一个分支下，但是由于Clearcase中没有“工作单元”的概念，因此不可能确定哪些更改属于哪个任务。 - Martin Harris

1

是的，你可以。创建两个视图，一个用于每个“任务”。然后，你可以使用 diff 工具和合并更改的能力将更改从一个分支移植到另一个分支。 - George Stocker

我感觉你在这里说的很有用，但我就是不理解。当你说“views”时，你是指快照视图吗？我并不是真的想将一个分支的更改合并到另一个分支，我正在寻找一种系统，在这个系统中，合并到主分支的更改不会显示在已经存在的分支中。 - Martin Harris

如果您删除配置规范中的以下行：element element * /main/LATEST -mkbranch martin_2322，那么您将无法自动获取对主干的更改。 - George Stocker

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- VonC · Accepted Answer

以下是一些评论：

对于在一个“工作单元”内修改一组文件，每个任务一个分支是正确的粒度。只要“任务”不是太窄，否则你会得到无数个分支（和它们相关的合并）。
当你为一个分支创建配置规范时，显然忘记了新元素的那一行（你“添加到源代码控制”中的那一行）。
此外，你可以考虑以修复起点为基础进行分支，这将解决“旧版本的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

相较于计算一个分支的日期，我更希望您能够轻松地完成这项任务。

不要忘记，您可以将您的任务合并回主分支，并且将一些已经完成的任务分支中的文件合并到您当前的新任务分支中，以便在需要时将您的修复措施反向适配到该当前任务上。