分散型バージョン管理ガイド

分散型開発の基礎については、Plastic Book の集中型と分散型に関する章をご覧ください。

このガイドでは、パッケージによるレプリケーションと直接レプリケーション、複数のサーバーにまたがる認証、コマンドラインと GUI を使用したレプリケートの方法、ブランチエクスプローラーによる分散型リポジトリの視覚化について説明します。

使用可能なレプリケーションモードは 2 つあります。

• サーバー間の直接レプリケーション - Plastic SCM クライアントは同期先サーバーに、ソースサーバーからブランチをレプリケートするように指示します。サーバーはインターネット接続またはイントラネット接続を介して通信し、データをレプリケートします。
• パッケージベースのレプリケーション - Plastic SCM クライアントはソースサーバーに接続し、レプリケーションパッケージを作成します。パッケージは（たとえば USB ドライブによって）直接配布され、後で同期先サーバーによってインポートされます。

次の図に、使用可能な 2 つのレプリケーションモードを示します。

パッケージベースのレプリケーションにより、セキュリティ制限のために直接接続できないサーバーを同期させることが可能になります。

上で説明したすべてのレプリケーションのシナリオと可能な操作は、Plastic SCM のコマンド push と pull を使用して管理できます。

ここで、srcbranch はレプリケートされるブランチとそのリポジトリを示すブランチ指定であり、destinationrepos はそのブランチをレプリケートする先のリポジトリです。

サーバー london:8084 のリポジトリ code にあるブランチ main を、bangalore:7070 にあるリポジトリ code_clone にレプリケートする必要があるとします。そのコマンドは次のようになります。

ブランチ main だけでなく、リポジトリ全体をレプリケートする必要がある場合は、clone コマンドを使用できます。

パッケージを使用してブランチをレプリケートするには、最初にレプリケーションパッケージを作成してから、そのパッケージを別のサーバーにインポートします。

サーバー box:8084 のリポジトリ code にある main ブランチのレプリケーションパッケージを作成する必要があるとします。

上のコマンドにより、main ブランチのすべてのコンテンツを含む box.pk という名前のパッケージが生成されます。

その後、このパッケージをリポジトリサーバー berlin:7070 にインポートします。

レプリケーションの際は、さまざまなサーバーが互いに通信する必要があります。つまり、異なる認証モードを実行しているサーバー間でデータをやり取りする必要が生じます。

そのために、レプリケーションシステムではさまざまな認証オプションを設定できます。

次の図は、1 つのクライアントと 2 つのサーバーがある、典型的なシナリオを示したものです。関与するすべての Plastic SCM コンポーネントは、LDAP で動作するように設定されていて、同じ LDAP 資格情報を共有するので、変換は必要ありません。

なお、認証は次の 2 つのレベルで発生します。

1. クライアントは、同期先サーバーに接続するために認証を受ける必要があります。図では、同期先サーバーは berlin です。
2. その後、berlin はレプリケート対象のブランチ（サンプルでは main）に関する情報を受け取るために、サーバー london に接続する必要があります。

両方のサーバーが同じ認証メカニズムを使用していない場合や、同じ LDAP 認証局に対して認証を行っていない場合、ステップ 2 は失敗します。

下の図は、サーバー london がユーザー/パスワード認証を使用するように設定されているというシナリオを示したものです。このケースでは、図の上部で指定されているようなコマンドが失敗します。サーバー間での認証がステップ 2 で機能しないためです。

この問題を解決するために、レプリケーションシステムにはサーバー間で使用される認証資格情報を指定する機能があります。この例の場合、クライアントはサーバー berlin に対し、サーバー london と通信するためのユーザーとパスワードを指定することができます。

次の図は、ソースサーバーでユーザー/パスワードを使用する際に認証資格情報を指定するための、2 種類の方法を示したものです。

1 つ目のオプションは、モードに加えて、ユーザーとパスワード（UP 用）をコマンドラインで指定する方法です。

2 つ目は、認証ファイルを使用する方法です。この方法は、認証資格情報が繰り返し使用される場合に便利です。図に示されているように、認証ファイルはシンプルなテキストファイルで、次の 2 つの行が含まれています。

• 認証の動作モード - UPWorkingMode、LDAPWorkingMode、NameWorkingMode、ADWorkingMode、または NameIDWorkingMode
• 認証モード用の固有の認証データ - 2 行目に指定されるデータは、設定ファイル client.conf の SecurityConfig セクションのデータとまったく同じです。

ここで、次の図に示すように、レプリケーションを逆方向（berlin から london への向き）で発生させる必要がある場合について考えてみましょう。LDAP サーバー（この場合は、LDAP を通じてアクセスされる Active Directory）に接続するためのパラメーターが指定されます。LDAP では通常、プロセスを簡単にするために認証ファイルが使用されます。

セキュリティモードの異なるサーバー間でレプリケーションが実行される場合、問題となるのは認証だけではありません。ユーザーとグループの ID が、異なるセキュリティモード間で変換される必要があります。

次の図のサンプルでは、ユーザー/パスワードの認証モードから、LDAP ベースの認証モードへのレプリケーションが試行されます。UP ノードのユーザーリストにはそのままの名前が格納されますが、LDAP サーバーのユーザーリストには SID が格納されます。レプリケートされるリビジョンの所有者が repA から repB にコピーされる必要がある場合は、repA のユーザーリストからユーザーまたはグループが取得され、repB のリストに取り込まれます。repA から取得された名前が repB のリストに直接取り込まれた場合、後でベルリンのサーバーが LDAP 識別子を解決しようとする際に、それが有効な名前ではないことが判明するため、問題が発生します。つまり、ユーザー/パスワードモードのユーザー識別子が LDAP ディレクトリのものと一致せず、レプリケートされたリポジトリでユーザー名が間違ったものになります。

そのため、この問題を解決するために、変換が必要になります。

Plastic のレプリケーションシステムでは、次の 3 つの変換モードがサポートされています。

• コピーモード - これがデフォルトの動作です。セキュリティ ID が、レプリケーション時にリポジトリ間でそのままコピーされます。これは、異なるリポジトリをホストしているサーバーが同じ認証モードで動作している場合にのみ使用できます。
• 名前モード - セキュリティ ID 間の変換が、名前に基づいて実行されます。前の図のサンプルで言うと、たとえば、ユーザー daniel を名前に基づいて repA から repB に変換する必要があるとします。その場合、repB では、Plastic SCM サーバーが名前 daniel を使ってユーザーを特定しようとし、必要であれば、その LDAP SID をテーブル内に取り込みます。
• 変換テーブル - このモードでも、名前に基づいて変換が実行されますが、テーブル主導のプロセスとなる点が異なります。ユーザーの指定したテーブルによって、名前の照合方法が同期先サーバーに伝えられます。これにより、ソースのユーザー名やグループ名を同期先の名前に変換するための方法が指示されます。次の図は、変換テーブルの構造と、異なる認証モード間での変換の方法を説明したものです。

レプリケーションは、コマンドラインインターフェース（CLI）と Plastic グラフィカルユーザーインターフェース（GUI）ツールのどちらからも実行できます。レプリケーションは主にブランチに関連しているため、可能なアクションはすべてブランチのオプションの下のサブメニュー内にあります。このトピックでは、ほとんどの一般的なレプリケーションアクションを GUI から実行する方法について説明します。

GUI では、レプリケーションおよび分散型コラボレーションは次のアクションに分類されます。

1. ブランチアクション：
1. 選択したブランチをプッシュ
2. 選択したブランチをプル
3. リモートブランチをプル
2. パッケージアクション：
1. 現在のブランチからレプリケーションパッケージを作成
2. ブランチからレプリケーションパッケージを作成
3. レプリケーションパッケージをインポート

次の図に、使用可能なさまざまな操作を示します。コマンドラインでは、すべての操作は単一のコマンドとして発行されますが、GUI ではプッシュ（自らのサーバーから同期先に変更を移す）とプル（リモートリポジトリの変更を自らのリポジトリに取り入れる）のアクションが区別されます。

すでに説明したように、ブランチメニューからすべてのレプリケーションアクションにアクセスできます（下の図を参照してください）。

オプション「このブランチをプッシュ」、「このブランチをプル」、および「このブランチからレプリケーションパッケージを作成」は、ブランチビューで現在選択されているブランチに関するオプションです。

それ以外のオプション「リモートブランチをプル」、「レプリケーションパッケージを作成」、および「レプリケーションパッケージをインポート」は、現在のブランチに限定されない汎用のレプリケーションアクションですが、すべてのレプリケーションオプションを一緒にまとめておくためにブランチメニューの下に置かれています。

変更をリモートリポジトリにプッシュする際には、ブランチメニューでこのブランチをプッシュを選択します。変更をプッシュするとは、選択されたブランチで加えた変更をリモートリポジトリに送信することを意味します。

• サーバー - 以前に同期先リポジトリからの複製を行ったことがない場合は、サーバー同期先名またはサーバー同期先 IP（およびポート番号）を入力する必要があります。
• サーバーを参照 - 自分のリポジトリでの過去のレプリケーションと、設定済みのプロファイルで利用可能なサーバーの一覧を表示します（詳細オプションをチェックしてください）。
  ブランチをプルすると、そのブランチの取得元（サーバーとリポジトリ）を記録するためのレコードが自分のリポジトリに作成されます。このサーバーは、その後のプッシュ操作やプル操作で、利用可能なサーバーとして使用されます。
• 「レプリケーション先」の「リポジトリ」 - 当該のブランチが同期先リポジトリにすでに存在している場合は、変更が同期されます。同期先で変更セットの競合がある場合は、警告メッセージが表示されます。その場合、開発者はまずブランチをローカルサーバーにプルし、その後（マージの競合が解決されたら）それをプッシュして変更を調整する必要があります。
  当該のブランチが同期先リポジトリに存在しない場合は、新しいブランチが作成されます（ソースリポジトリで使用されているのと同じ GUID によって識別されます）。
• リポジトリを参照 - 同期先サーバーのリポジトリを参照します。サーバーにアクセスする権限がない場合は、詳細オプションでプロファイルを選択または作成する必要があります。

ブランチを別のリポジトリにプッシュしたら、そのブランチはリモートで変更できるようになります。以後、何らかのタイミングで、自分のブランチにリモートで加えられた変更を取得したいと思うときが来るでしょう。それを実行するには、レプリケーションバッチメニューからこのブランチをプルのアクションを使用する必要があります。

次の図に示すダイアログボックスは、変更をプッシュするのに使用したものと非常に似ていますが、今回は、自分のサーバーが操作の同期先として右側に配置されています。

リモートブランチから変更をプルする際、2 つの場所に変更セットの競合がある場合は、サブブランチが作成される可能性があります。

レプリケーションの際のもう 1 つの一般的なシナリオは、リモートリポジトリから自分のリポジトリにブランチをインポートして変更を開始したり、そこから子ブランチを作成することです。

インポートを実行するには、「リモートブランチをプル」オプションを使用します。次の図のようなダイアログボックスが表示されます。ここでは、ソースサーバー、リポジトリ、ブランチ、およびお使いのサーバー上の同期先リポジトリを選択できます。

「認証」の章での説明のように、さまざまな Plastic SCM サーバーが異なる認証モードを使用している可能性があります。デフォルトでは、リモートサーバーへの接続を試行するときは、現在のプロファイル（お使いのサーバーに接続するときに使用された設定）を使用します。しかし、このデフォルトのプロファイルがリモートサーバー上で有効でない場合もあります。

別の認証モードを使用してリモートサーバーに接続できるように Plastic SCM を設定するには、レプリケーションダイアログの「詳細オプション」ボタンを使用します。次の図のようなダイアログが表示されます。

このダイアログボックスには、現在選択されているプロファイル（このスクリーンショット上ではデフォルトのプロファイル）、変換モード（詳細については「認証」の章を参照）、オプションの変換テーブルが表示されます。

「リモートサーバーの設定プロファイル」編集ボックスの右側にある「参照」ボタンを使用して、以前のレプリケーション操作からさまざまな認証プロファイルを作成してリストするか、新しいプロファイルを作成できます。

下の図のようなダイアログボックスが表示され、ここでプロファイルを選択、編集、作成、削除できます。

ここまで、すべてステップはレプリケーションプロセスのセットアップに関するものでした。操作が正しく設定された後、「レプリケート」ボタンを押すと、下の図で説明されているようなレプリケーションの進捗状況ダイアログボックスが表示されます。

レプリケーション操作は、主に次の 3 つの状態に分けられます。

• メタデータのフェッチ - ソースサーバーで発生します。
• メタデータのプッシュ - 同期先で発生します。
• リビジョンデータの転送 - データがソースから同期先へと転送されるため、2 つのサーバーが関与します。

操作は、「キャンセル」ボタンを押すことでいつでもキャンセルできます。

レプリケーション操作が完了すると、作成されたオブジェクトの数に関する詳細情報を含んだサマリーが表示されます。

レプリケーションパッケージは、リポジトリにあるブランチや、接続可能なサーバーにある任意のブランチから作成できます。ブランチビューで、選択したブランチからパッケージを作成するには、「このブランチからレプリケーションパッケージを作成」をクリックします。

リモートブランチからパッケージを作成する必要がある場合は、レプリケーションメニューの「レプリケーションパッケージを作成」をクリックします。

上の図は、パッケージ作成ダイアログを示します。選択したブランチからレプリケーションパッケージを生成します。そのパッケージには、選択したブランチのすべてのデータとメタデータが含まれます。これは、直接接続できないサーバー間でレプリケートするのに使用できます。

レプリケーションメニューから「レプリケーションパッケージをインポート」を選択し、インポートするパッケージファイルを選択します。次の図のようなダイアログボックスが表示されます。

ブランチエクスプローラーは Plastic SCM GUI のコア機能の 1 つであり、分散型のシナリオに対処できるように最近のリリースで大幅に改善されています。そのため分散型ブランチエクスプローラーと呼ばれるようになりました。略称は DBrEx です。

レプリケートされた 2 つの Plastic SCM サーバーがあるとします。以下に示すように、1 つは中央のサーバー上で実行されており、もう 1 つはノート PC 上で実行されています。

まず、ノート PC 上で実行されているサーバーが、中央のサーバーから main ブランチをレプリケートしました。後に task002 が作成され、開発者はそこで作業しました。ある時点におけるそのシナリオは、次のようになります。

DBrEx は、異なるソースからデータを収集し、その後に単一のダイアグラム上にある変更セットとブランチを次の図に示すようにレンダリングすることで、分散型のダイアグラムをレンダリングできます。

DBrEx は異なるソースを組み合わせ、異なるソースから収集された情報を使用して、対話型のダイアグラムを作成します。

複数のレプリケート済みリポジトリを同じ DBrEx ダイアグラム内に結合するには、いくつかのオプションがあります。1 つ目のオプションは、選択したレプリケーション元から取得したすべての変更セットとブランチを含む、結合済みのレンダリングを作成するために使用されます。次の図は、ダイアグラム設定の開始方法を示したものです。

「レプリケーション元」タブには、DBrEx でレンダリングされるリポジトリから変更をプルするために使用されたリポジトリ（または、アクティブなリポジトリに変更をプッシュしたリポジトリ）が表示されます。

（「リモートデータを表示する」チェックボックスをクリックして）1 つ以上のレプリケーション元をクリックすると、下の図のように、分散型のダイアグラムがレンダリングされます。ダイアグラムは展開されていて、リモートリポジトリからの情報が示されています。

このように、分散型のブランチエクスプローラーでは、プロジェクトやブランチが複数のレプリカ間でどのように進化するかを理解するための、新しい方法が導入されています。

また、DBrEx からレプリケーション操作を実行することもできるので、DBrEx でレンダリングされるリモートブランチを選択し、「このブランチをプル」をクリックするだけで、リモートブランチを簡単にプルできるようになりました。リモートのブランチと変更セットは「差分表示」でも利用可能なので、分散型による変更の操作が大幅に強化されます。

DBrEx のリモートブランチまたは変更セットを右クリックして、何がリモートで変更されたかを調べることができます。この方法により、開発者またはインテグレーターは操作を実行する前にリモートソースからどのような変更がプルされるかをより詳しく把握することができます。次の図は、リモート変更セット上で有効にされたオプションを示します。

SCM マネージャーや開発者は特定のブランチにのみフォーカスする必要があるため、分散型のダイアグラム全体をレンダリングする必要はないことがあります。

上の図は、「ブランチエクスプローラー」/「現在のブランチのリモート変更セットを表示」メニューオプションを示します。そこでは、リモートソースを選択してブランチにリモートデータを付加することで何をプルする必要があるかを把握し、エクスプローラーの差異を確認して、レプリケーションコマンドをトリガーできます。

Plastic SCM で最も重要なのは、チームが分散型開発を導入できるように支援することです。そのために DBrEx を強化しましたが、数百もの分散型の変更セットを扱うために、新しい視点として分散型のビューを作成しました。

この同期ビューにより、任意のリポジトリのペアを簡単に同期し、プッシュまたはプルが必要な保留中の変更を参照して差分を確認することができます。

同期の操作方法の詳細については、GUI ガイドの「同期ビュー」セクションを参照してください。

2019 年 3 月 22 日

2019 年 3 月 20 日

2019 年 2 月 15 日

2017 年 5 月 12 日