ストリームを使用していることを確認してください (つまり、別のユーザーをシミュレートする別のリポジトリ ワークスペースに直接配信しないようにしてください)。
(注: これは ClearCase ではまったく異なります。この場合、リベース後に UCM ビューの構成とストリームの構成の間で「非同期」が発生する可能性があります)
別のリポジトリ ワークスペース (別の Eclipse ワークスペースに読み込まれる) を作成すると、同じ Eclipse インスタンス内で使用すると混乱が生じる可能性があります。
このスレで言ってる通り
リポジトリ ワークスペースは、変更を分離するためのものであり、プライベート ストリームです。
変更が自動的に受け入れられるわけではないため、流入するものを完全に制御できます。それらに対してプライベート ビルドを実行することもできます。それが全体の考えです。
共有コードを使用して複数のリポジトリ ワークスペースを実行する場合は、ストリームを使用する必要があると思います。
クリーン リポジトリ ワークスペースは、ストリームに配信することを決定した変更を受け入れるために使用されます。
したがって、リポジトリ ワークスペースをストリームとして使用しようとしています。それらはほとんど同じですが、配信された変更にどのように反応するかはわかりません. 特にロード中。
2 つの Eclipse インスタンスを使用する必要があります。同じ Eclipse プロジェクトが同じサンドボックスと同じ Eclipse に複数回ロードされることを懸念しています。
その「混乱」は同じスレッドで説明されています。
これは予期される動作です。
配信して WS1 を変更しても、ディスクにロードしたコンテンツWS1
は更新されません。したがって、リロードする必要があります。
このため、他のユーザーのワークスペースに配信することはできません。他のユーザーのワークスペースを変更することはできませんが、自分のワークスペースを変更することはできます。同期が取れなくなった理由がわかるためです。
「 Rational Team Concert Source Control ユーザー向けのグッド・プラクティスと主要なワークフロー」のポイント 7 と 10 を確認してください。
注: 記事「Rational Team Concert 2.0 で Jazz ソース管理リポジトリーからコンテンツをロードする」(RTC3.0 にも有効) のセクション「非同期共有フォルダーの再ロード」で、 OP:
ローカル ワークスペースは、いくつかの理由により、リモート ワークスペースと同期しなくなる可能性があります。
- リモート ワークスペースが複数回読み込まれ、変更がチェックインされたか、別のクライアント セッションから受け入れられました。
- ローカル ワークスペースとリモート ワークスペースの両方を変更する操作 (Accept など) 中にエラーが発生しました。
RTC 1.0 でローカル ワークスペースがリモート ワークスペースと同期しなくなると、ユーザーはロード ウィザードを実行し、再ロードが必要なフォルダを再選択する必要がありました。
RTC 2.0 では、この新しいオプションにより、同期されていないフォルダーが自動的に選択されて再読み込みされるため、同期されなくなります。
RTC 2.0 の新機能として、以下に示すように、同期していないプロジェクトがあることを [保留中の変更] ビューに表示することもできます。
ビューをクリックするとReload out of sync link in the Pending Changes
、読み込みウィザードが開きます。
リロード オプションはデフォルトで選択されており、[次へ] をクリックすると、リロードするフォルダを選択できます。
次のスクリーン ショットでわかるように、Foundation コンポーネントのすべてのプロジェクトが同期されておらず、再読み込みする必要があります。
クリックするFinish
と、これらのフォルダがリロードされ、同期がとられます。
また、「同期されていないプロジェクトを処理する方法」というスレッドは、そのメカニズムの興味深い例を提供します (実際の状況とは異なりますが)。