我之前documented我对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并将结果合并回main。现在我回到2322工作，所以我将配置规范改回到上面定义的规范。此时我看到来自任务分支的A.cs文件（我之前编辑过它，所以我得到了该分支的本地版本）和来自main的最新版本的B.cs。由于我没有对2345分支上的A.cs进行更改，因此构建中断。我需要的是能够从我离开的地方获取任务2322并使用旧版本的A.cs查看它 - 在创建分支时最新的主要版本。
我看到它的方式我有几个选项来解决这个问题：
更改配置规范，以便在正确的日期从main获取文件。如果我知道日期并且不介意手动设置它，这很容易做到，但我无法弄清楚如何将其自动化到我们的任务切换脚本中。无论如何都要获得分支的创建日期？
为main上的每个分支创建一个标签。理论上很简单，但是我们安装的CC中的标签系统已经在几百个标签的重压下崩溃，所以我不知道它是否会应对每个分支机构的每个开发人员（请注意我的示例中的任务）是2322，我们只是项目的四分之一左右）
从main合并到任务分支。再次应该工作，但是长时间运行的分支不仅包含为该任务更改的文件，而是需要合并的所有文件以使不相关的东西工作。这使得它们像每个开发人员分支方法一样复杂。我想查看哪些文件已更改以完成特定任务。
我希望我在这里遗漏了一些东西，并且有一种设置我的配置规范的方法，以便它从main检索预期的文件，而不用笨重的解决方法。那么，你们如何在Clearcase中分支？
答案 0 :(得分：4)
一些评论：
每个任务的分支是用于修改“工作单元”内的一组文件的正确粒度。如果“任务”不是太狭窄，否则你最终会得到一个分支（以及它们相关的合并）
当您为分支创建配置规范时，您显然忘记了 new 元素的行（您“添加到源代码管理”的元素）
另外，您可以考虑分支修复起点，这将解决“旧版本的A.cs - 创建分支时最新的主要版本”位。
我知道你已经有太多的标签，但是你可以有一个脚本来“关闭”一个任务，这个任务会（除其他外）删除那个起始标签，避免标签混乱。
这里我将使用配置规范：
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
我会发现这比计算分支的日期要容易得多。
答案 1 :(得分：2)
您可以使用cleartool中的 describe 命令获取分支的创建日期。
cleartool describe -fmt "%d" -type martin_2322
这将打印出创建分支的日期和时间。您可以使用它来实现您的第一个选项。有关更多信息，您可以阅读以下cleartool手册页，但希望上面的命令是您所需要的。
cleartool man describe
cleartool man fmt_ccase
答案 2 :(得分：1)
我们使用Clearcase，我们发现为发布创建分支通常比按任务执行更容易。如果您确实按任务创建它，那么我将为该版本提供一个“主分支”，并将该任务分支出该分支，然后在完成时将它们合并回来以将它们合并回主干。