1

I have 3 projects A, B based on A, C based on A.

Changes A should first be merged to B and then from B to C. There are also changes in B not affecting A but some of this changed need to be merged in C.

There some changes from A which have been incorrectly merged directly from A to C bypassing B. (I'm using the word "merged" because we needed to merge those manually because automatic delivery would include a bunch of activities we don't need to deliver to B and C).

この問題を解決するには、B ではマージされていないが、C でマージされた変更を B でマージする必要があります。A からマージすることによって作成された C のすべてのバージョンを一覧表示する方法を探しています。これらのファイルの変更を B にマージできることを確認しました。

ありがとう

4

1 に答える 1

2

A からマージして作成された C のすべてのバージョンを一覧表示する

これらのバージョンは、A から C に直接マージしたときに作成する必要があるマージ アクティビティにリストされている必要があります (使用するfindmergeと思います)。

唯一の問題は、その間に特別な「マージ」アクティビティを作成したfindmergeかということです。
C で現在のアクティビティを再利用しただけかもしれません。つまり、アクティビティには、C での現在の作業からのバージョンと、A からマージされたバージョンが含まれます。

もう 1 つのアプローチは、同じアクティビティ (A から C への findmerge に関連するもの) を A
から B にマージすることです。B から C への次の「通常の」マージは、次のようになります。

  • A から既にマージされたファイルに対しては何もしません (この「他のアプローチ」に従って B にもマージされているため)。
  • 他の変更されたファイルの B から C への進化をマージします。

これらのマージには使用しませんでした。A の対応するアクティビティに対して C で同一のアクティビティを作成し、ファイルごとにマージする GUI バージョン ツリー ツールから使用しました。

マージするファイルが 1 つまたは 2 つしかない場合を除き、使用するコマンドfindmergeは次のとおりです。

  • 1つまたは複数のアクティビティを考慮できます
  • また、デリバーまたはリベース UCM 操作で強制されるものと同じ「アクティビティの依存関係」に拘束されません。

つまり、findmerge従来のマージで、UCM アクティビティ内のバージョンを読み取ることができますが、非 UCM マージ (UCM ベースライン間のハイパーリンクなし) を行います。

于 2009-07-08T15:22:36.850 に答える