2017-08-04 15 views
2

コード開発はほとんどの場合、mainブランチで行われます。ある時点では、互いに密接に関係しているいくつかの新機能に取り組む時です。このために、新しいブランチsome_feature_setを作成しました。複数の開発者がこの機能セットで作業します。各開発者はそれぞれのブランチで作業し、特定のサブフィーチャが終了したとみなされると、some_feature_setにマージされます。フィーチャセットが完全に実装されたら、それをmainにマージすることです。ネスト分岐のClearCase設定仕様

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から分岐した:

は、私たちはこの1つのような設定の仕様を使用し、これを達成するために。

私たちの組織はダイナミックビューを使用しています(これは変更できません)。他の開発者がmainsome_feature_setブランチを変更してサブフィーチャーブランチで進行中の作業を壊す可能性があるので、私たちはタイムスタンプを使用します。設定の仕様は、したがって、次のようになります。mainからファイルをチェックアウトするとき

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 

これは、問題が発生します。 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は別の開発者によって作成されます。 config specのルールは、依然としてバージョン/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ではありません。他の開発者がファイルをチェックアウトする前と同じです。

上記の問題を防ぐためにできることはありますか?

答えて

1

最初に、と同じ機能を開発するための開発者ごとに1つのブランチがベストプラクティスではありません。私はそれに対して長い間提唱してきた(since 2009)。

しかし、サブブランチが必要な場合は、時間に頼るのではなく、ラベルから作成する方がはるかに効果的です。私が持っている
そして、それは分岐パスを強制しないことが最善である(あなたの質問が示すように、それは、あまりにも気難しいなり)

は「ClearCase : Loading Older Version of a specific Directory?」で、時間ベースの選択ルールを使用しています。
しかし、あなたは新しい要素のためのルールが表示されますが、単純に、一度、ソニーの現れでもある。

element * /main/0 -mkbranch myBranch 

あなたはそれが正しいブランチで直接作成したいことを、新しい要素のために、指定する必要があります。

これは、ブランチベースの選択ルールが、​​3210のように省略記号表記...を使用する理由です。 「Details of config spec in base ClearCase」を参照してください。

一般的な考え方は、開始バージョンが正しいバージョン(すなわち、不変のラベルが正しいもの)である限り、新しいブランチが作成されるブランチを気にするべきではありません。

+0

私の言葉はおそらく間違っていました。私が 'some_feature'と言ったところでは、家族の大きなサブファミリーのファミリーを意味し、私が 'some_task'と言ったところで、私はこれらの 'sub_features'のうちの1つを意味しました。私はワークフローが開発者指向ではなく、仕事指向でなければならないことを理解しています。私は私の質問を更新します。 –

+0

@ TudorTimi私は同意するが、私の答えはまだ立っている。 ...を使用することが望ましい。 – VonC

+0

timestamptとlabelの関係については、中間のマイルストーンを定義していないため、ラベルはありません。現在、タイムスタンプしかありません。リリース以外の目的でラベル付けについて話すのは面白いでしょう。私はこれについて新しい質問をする必要があります。 –

関連する問題