保留状態のチェンジリストの昇格
エッジサーバ上の保留状態のチェンジリストは、通常他のエッジサーバからアクセスできませんが、自動的または明示的にコミットサーバに昇格することができます。 昇格された保留状態のチェンジリストは、どのエッジサーバでも使用可能です。
- 共有されたアーカイブ構成では、コミットサーバとエッジサーバは同じストレージデバイスでアーカイブされたコンテンツにアクセスできます。保留状態は、自動的にコミットサーバに昇格されます。 詳細については、自動的に保留状態を昇格するを参照してください。
- コミットサーバとエッジサーバがアーカイブを共有していない場合、保留状態を明示的に昇格する必要があります。 詳細については、明示的に保留状態を昇格するを参照してください。
p4 describeコマンド、p4
changesコマンド、またはp4 change -oコマンドの-ztag出力を使用して、保留状態の昇格ステータスを表示できます。
昇格された保留状態の操作の制限に関する詳細については、昇格された保留状態を操作するを参照してください。
自動的に保留状態を昇格する
エッジサーバとコミットサーバが同じアーカイブコンテンツにアクセスできるように設定される場合、保留状態の昇格は、自動的に行われます。p4 shelve -pを使用した保留状態のフィールドの昇格は必要ありません。
エッジサーバとコミットサーバが同じアーカイブコンテンツにアクセスできるように設定するには、コミットサーバとエッジサーバの両方で同じパスにserver.depot.rootを設定してください。また、エッジサーバでlbr.replication構成可能変数をsharedに設定してください。 以下に例を示します。
$ p4 configure set commit#server.depot.root=/p4/depot/root
$ p4 configure set edge#server.depot.root=/p4/depot/root
$ p4 configure set edge#lbr.replication=shared
明示的に保留状態を昇格する
明示的に保留状態を昇格させるには、2つの方法があります。
-
dm.shelve.promote構成可能変数の値を「1」に設定する重要この場合、エッジサーバによって保留中のファイルが自動的にコミットサーバに昇格されます。このファイルの内容は、コミットサーバとエッジサーバの両方に転送されて保存されます。
この方法の場合、パフォーマンスが低下します。
エッジサーバ上でHelix Swarmを使用している場合は、自動昇格機能が必要になります。 『Helix Swarmガイド』の「Swarm用のHelix Coreサーバの構成」で、「保留中のすべての変更を昇格させるようにHelixサーバを設定する」を参照してください。
-
-pオプションは、p4 shelveコマンドとあわせて使用するこのオプションについて詳しくは、以下の例を参照してください。
例えば、edge1とedge2の2つのエッジサーバがあるとします。
-
edge1からチェンジリストを保留し、昇格させます。edge1$ p4 shelve -p -c 89
-
保留状態のチェンジリストが
edge2で使用できるようになります。edge2$ p4 describe -S 89
-
昇格が必要となるのは、一度のみです。
続けて
p4 shelveコマンドを入力することで、コミットサーバの保留状態のチェンジリストを、サーバロックプロテクションにより自動的に更新できます。 例えば、edge1に変更を加えて、保留済みのチェンジリストを再表示します。edge1$ p4 shelve -r -c 89
更新が
edge2に表示されました。edge2$ p4 describe -S 89
クライアントのアンロード時に保留状態を昇格させる
p4 unloadコマンドの-pオプションを使用することで、アンロードされる特定のクライアントに属する、まだ昇格されていない保留状態を昇格させることができます。 他のエッジサーバからアクセスできる場合は保留状態がコミットサーバに昇格されます。
昇格された保留状態を操作する
以下の操作を行うことができます。
- チェンジリストから保留状態のファイルを削除できます。ただし、保留状態のチェンジリストを降格することはできません
- 昇格した保留状態をオープンファイルまたは別のサーバ上のブランチに保留解除できます
- 変更を保持しているサーバでのみ、昇格された保留状態に
p4 submit -eを実行できます p4 unshelveコマンドを使用して、昇格された保留状態を、あるエッジサーバから別のエッジサーバに移動できます
