【问题标题】:ClearCase config spec for nested branching用于嵌套分支的 ClearCase 配置规范
【发布时间】:2017-08-07 17:17:01
【问题描述】:

我们有一个 VOB,其中代码开发主要在 main 分支中完成。在某个时间点,是时候开发一些彼此密切相关的新功能了。为此,我们创建了一个新分支some_feature_set。多个开发人员致力于此功能集。每个开发人员都在自己的分支中工作,一旦某个子功能被认为完成,它就会被合并回some_feature_set。一旦功能集完全实现,计划将其合并到main

为了实现这一点,我们使用如下配置规范:

element * CHECKEDOUT
element * /main/some_feature_set/some_sub_feature/LATEST
element * /main/some_feature_set/LATEST -mkbranch some_sub_feature
element * /main/LATEST -mkbranch some_feature_set

由于some_sub_feature 的工作打算合并到some_feature_set,我们的想法是在创建任务分支之前已经从some_feature_set 分支。

我们的组织使用动态视图(我们无法更改)。为了保护我们自己免受其他开发人员对mainsome_feature_set 分支所做的更改可能会破坏子功能分支中正在进行的工作,我们使用时间戳。因此,配置规范看起来像这样:

element * CHECKEDOUT
element * /main/some_feature_set/some_sub_feature/LATEST
mkbranch some_sub_feature
  element * /main/some_feature_set/LATEST -time <some_time>
  mkbranch some_feature_set
    element * /main/LATEST -time <some_time>
  end mkbranch
end mkbranch

这会导致在从main 签出文件时出现问题。 ClearCase 会将其分支到some_feature_set,但由于没有规则选择新创建的版本,它会尝试再次分支并发出分支存在的错误。我们可以通过在配置规范中添加更多规则来解决这个问题:

element * CHECKEDOUT
element * /main/some_feature_set/some_sub_feature/LATEST
mkbranch some_sub_feature
  element * /main/some_feature_set/LATEST -time <some_time>
  element * /main/some_feature_set/0
  mkbranch some_feature_set
    element * /main/LATEST -time <some_time>
    element * /main/0
  end mkbranch
end mkbranch

这样我们在签出文件或将新文件添加到 ClearCase 时不会遇到任何问题。但是,我们确实遇到的问题是,当另一个开发人员想要为只有main 分支的文件的some_feature_set 分支做一些工作并检查这个文件时,视图选择的版本将会改变。

假设,例如,对于上面列出的配置规范,在我看来,/main/4 版本被选为some_file。工作继续并行,版本/main/5 由不同的开发人员创建。配置规范中的time 规则仍将选择版本/main/4。在稍后的某个时间点,另一个开发人员必须为some_feature_set 做一些工作,并设置一个具有类似配置规范但具有更新时间戳的自己的视图,以便some_file 选择版本/main/5。该开发人员必须对some_file 进行一些更改并进行检查。这会立即创建版本/main/some_feature_set/0/main/some_feature_set/some_other_sub_feature/0。因为/main/some_feature_set/0 现在存在,所以我的视图选择了它。它的内容与/main/5 相同,而不是/main/4,就像其他开发人员签出文件之前的情况一样。

有什么办法可以防止上述问题的发生吗?

【问题讨论】:

    标签: clearcase


    【解决方案1】:

    首先,每个开发人员一个分支来开发相同功能并不是最佳实践。我一直反对这种做法 (since 2009)。

    但是如果你必须并且想要子分支,那么从标签创建它们会更有效,而不是依赖时间。
    并且最好不要强制分支路径(如您的问题所示,它变得太挑剔了)

    我在“ClearCase : Loading Older Version of a specific Directory?”中使用了基于时间的选择规则。
    但是你会看到新元素的规则既简单又出现一次:

    element * /main/0 -mkbranch myBranch
    

    您需要为 new 元素指定您希望它直接在正确的分支中创建。

    这就是为什么基于分支的选择规则通常使用省略号符号...,如.../myBranch。见“Details of config spec in base ClearCase”。

    一般的想法是:你不应该关心新分支是从哪个分支创建的,只要它的起始版本是正确的(即具有正确的不可变标签的那个)。

    【讨论】:

    • 我的措辞可能是错误的。我所说的“some_feature”是指一些大家族的子功能,而我所说的“some_task”是指其中一个“sub_features”。我理解工作流应该面向工作而不是面向开发人员。我会更新我的问题。
    • @TudorTimi 我同意,但我的回答仍然有效。最好使用 ...。
    • 关于 from timestampt vs. from label,我们没有任何标签,因为我们没有定义任何中间里程碑。目前我们只有时间戳。谈论标签用于发布以外的目的会很有趣。我将不得不就此提出一个新问题。
    • @TudorTimi 出于好奇,为什么你在 2017 年还有 ClearCase?
    • 我从事硬件开发工作,我们的设计流程仍然以基本 ClearCase 为中心(没有任何类型的工作流程)。基本上每个人都检查 /main/LATEST,互相踩着脚尖,只使用 ClearCase 进行备份。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2013-04-19
    • 1970-01-01
    • 1970-01-01
    • 2015-01-19
    • 2018-08-09
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多