ソフトウェア開発支援
IR情報 会社情報
image_toyo_ss_img_perforce_title_perforce.gif.gif
テクニカルノート030  
image_toyo_ss_img_all_line_yellow.gif.gif
image_toyo_common_spacer.gif.gif
リモート・ディポの使用が適切である場合と適切でない場合
image_toyo_common_spacer.gif.gif
問題
image_toyo_common_spacer.gif.gif
どのような場合にリモート・ディポを使用するべきでしょうか。
image_toyo_common_spacer.gif.gif
解決策
image_toyo_common_spacer.gif.gif
image_toyo_ss_img_all_line_dot_526.gif.gif
image_toyo_common_spacer.gif.gif
リモート・サイトのユーザをサポートする
image_toyo_common_spacer.gif.gif
PERFORCE の新規のお客様は、ユーザが地理的に分散されている場合、別の PERFORCE インストールを リモート・ディポ・サポートで接続してセットアップする必要があると考えるかもしれません。 しかし、分散された開発組織であっても単一の PERFORCE インストールを使用することで生産性が 向上する場合も多くあります。
image_toyo_common_spacer.gif.gif
ここでいう「インストール」とは、任意の数のディポおよびクライアント・ワークスペースを 管理する PERFORCE サーバです。 PERFORCE サーバにより管理されるディポは、PERFORCE サーバが 稼働するマシンのローカルにあります。それらのディポにあるファイルは、その PERFORCE サーバにより 管理されるクライアント・ワークスペースを持つどのユーザからもアクセスが可能です。PERFORCE は 大規模なネットワークの待ち時間に対処するように設計されているため、本質的にリモート・サイトの クライアント・ワークスペースを持つユーザをサポートします。したがって、1つの PERFORCE インストール により、近いサイトと遠いサイトで作業するメンバーを有する共用開発プロジェクトに対応することができます。
image_toyo_common_spacer.gif.gif
一方リモート・ディポは、共用開発ではなく共用コードをサポートするように設計されています。 それらは、独自のPERFORCEサーバを有する独立した組織が、他のインストールにあるファイルを 参照したり、ディポから変更を反映したりすることを可能にします。リモート・ディポはロード・ バランシングやネットワーク・アクセス障害への対応策ではありませんが、それらの領域で克服不可能な 問題に、リモート・ディポを使用して対処することもできます。
image_toyo_common_spacer.gif.gif
このテクニカルノートでは、以下に示すような分散開発組織に関する問題について記述します。
image_toyo_common_spacer.gif.gif
リモート・サイトのユーザをサポートする
リモート・ディポはどのように機能するか
リモート・ディポの制限
結論および推奨事項

image_toyo_common_spacer.gif.gif
image_toyo_ss_img_all_line_dot_526.gif.gif
image_toyo_common_spacer.gif.gif
1つのPERFORCEサーバがあり、リモート・サイトがない場合
image_toyo_common_spacer.gif.gif
1つ以上のソフトウェア・プロジェクトの開発を分担する分散された組織には、 1つのPERFORCEサーバ、1つ以上のPERFORCEディポ、多数のPERFORCEクライアント・ワークスペースが あることが最適です。ワークスペースの地理的な位置はPERFORCE サーバとは無関係です。
image_toyo_common_spacer.gif.gif
image_toyo_ss_perforce_clip_note030-fig1.gif.gif

image_toyo_common_spacer.gif.gif
図1: 1つのPERFORCEインストールでリモート・ユーザをサポートする
image_toyo_common_spacer.gif.gif

image_toyo_common_spacer.gif.gif
image_toyo_ss_img_all_line_dot_526.gif.gif
サポートされるユーザの数
image_toyo_common_spacer.gif.gif
リモート対応は、PERFORCEサーバのユーザをサポートする機能の一要素ではありません。 しかし、全体のユーザ数はその要素に数えられるかもしれません。 また、PERFORCEサーバとユーザのリモート・サイトとの間のネットワーク回線の速度と品質は 明らかにその要素に挙げられます。
image_toyo_common_spacer.gif.gif
リモート・サイトでは、生産的に作業することができるユーザの数はサイトのネットワーク接続に依存します。 PERFORCE 99.1およびそれ以降で利用可能なデータ圧縮機能を使用することにより、 低速なモデム回線では1-3ユーザ、64KB回線では20-30ユーザ、T1回線(1MB/秒)では100人以上のユーザを サポートすることが予測されます。ローカルのイーサネット(10MB/秒)は企業全体をサポートするでしょう。 もちろん、これらの予測はユーザが行う作業に依存します。プレーンテキストのソースファイルで40人のユーザが 作業する場合は、おそらく64KBの回線で十分でしょう。しかし、圧縮されていない場合には特に、絶えず 大きいGIF画像を更新しているユーザが2人いるとその回線が飽和状態となり、他のすべてのユーザが不便を 強いられることになります。
image_toyo_common_spacer.gif.gif
単一のPERFORCEインストールで近くまたは遠くのサイトにいる多数のユーザをサポートしている場合、 制限的なクライアント・ビューおよびアクセス権限を使用して、各ユーザが自分の作業中のディポおよび サブディレクトリにのみアクセスするよう設定することにより、PERFORCEサーバの負荷を減少させることができます
image_toyo_common_spacer.gif.gif
ネットワーク接続されたサイトのWindowsユーザは、P4WinよりもPERFORCEコマンドライン・クライアントであるp4を 使用するとより効率よく作業できます。それは、P4Winの現在のリリースではPERFORCEサーバからの舞台裏での データ更新要求を頻繁に起こさせるためです。
image_toyo_common_spacer.gif.gif
image_toyo_ss_img_all_line_dot_526.gif.gif
image_toyo_common_spacer.gif.gif
ネットワーク・セキュリティ
image_toyo_common_spacer.gif.gif
接続の両端でのファイアウォールの通過に、SSH(セキュア・シェル)パッケージを使用することをお勧めします。 公開鍵暗号方式により一方の端にあるホストのIDを検証した後、通常の暗号方式によりデータ・ストリームを安全に 保つことで、安全が確実に保たれるように設定することができます。さらに、SSHは暗号化する間に圧縮を行うため、 低速なモデム回線で有効です。SSHについてより詳しくは、テクニカルノート022:ファイアウォール経由で PERFORCE にアクセスする方法 を参照してください。
image_toyo_common_spacer.gif.gif
image_toyo_ss_img_all_line_dot_526.gif.gif
image_toyo_common_spacer.gif.gif
リモート・ディポを持つ複数のPERFORCEサーバ
image_toyo_common_spacer.gif.gif
リモート・ディポ・サポートがない場合、クライアント・ワークスペースはそれが属するインストールにある ディポにのみアクセスできます。リモート・ディポ・サポートの目的は、クライアントが他のインストールにある ディポにアクセスできるようにすることです:
image_toyo_common_spacer.gif.gif
image_toyo_ss_perforce_clip_note030-fig2.gif.gif

image_toyo_common_spacer.gif.gif
図2: 他のインストールにあるディポにアクセスするためのリモート・ディポ・サポート

image_toyo_common_spacer.gif.gif
上の図は、サーバ・ポート・アドレスに "mars:1666" を使用しているPERFORCEインストールを示しています。 mars:1666のPERFORCEサーバが稼動しているマシンが物理的に当該ユーザの近くにあるか否かに関係なく、 P4PORTをmars:1666に設定していれば、これがP4またはP4Winを使用する際の「ローカルの」PERFORCEサーバになります。 mars:1666のPERFORCEサーバは、自身のディポにあるファイルを管理し、チェンジリスト、反映履歴、 クライアント・ワークスペース、およびその他のメタデータからなるデータベースを保持します。 ユーザが適切なアクセス権限を持っている限り、そのPERFORCEサーバにあるすべてのメタデータを使用でき、 PERFORCEサーバのディポにあるファイルに変更をサブミットすることができます。 mars:1666によって管理されているディポが、「ローカルの」ディポになります。
image_toyo_common_spacer.gif.gif
それでは、 "venus:1666" の PERFORCEサーバによって管理されるディポのファイルにアクセスしたい場合を考えます。 P4PORTをvenus:1666に設定したとすると、venus:1666がローカルのPERFORCEサーバとなります。 これでP4コマンドおよびP4Winコマンドは、そのPERFORCEサーバと通信するようになります。 しかし、venus:1666の PERFORCEサーバは、mars:1666がローカルのPERFORCEサーバであったときに使用されていた クライアント・ワークスペースを認識しないので、新しいクライアント・ワークスペースを設定しなければなりません。 実際、venus:1666のPERFORCEサーバはユーザとmars:1666のPERFORCEサーバとの関係について、 ユーザがどのようなアクセス権を持っているか、クライアント・ビューはどうなっているか、 ワークスペースで作業状態にしているファイルはどれかなど何も認識していません。 そのため、venus:1666のディポからのファイルを、mars:1666ワークスペース内のファイルと比較または マージしたい場合、ローカルのPERFORCEサーバとしてvenus:1666 に接続しても役に立ちません。
image_toyo_common_spacer.gif.gif
PERFORCEのリモート・ディポ・サポートにより、ユーザはローカルPERFORCEサーバとしてmars:1666に 接続しているときにも、venus:1666ディポのファイルにアクセスすることができます。 例えば、"//venus" というリモート・ディポを、venus:1666の "//depot2" パスにマッピングして 定義することができます。これを行った後は、p4コマンドを使用して//venusパスにあるファイルを 参照することができます。例えば、
        p4 diff2 //venus/elm2.1/... //depot/elm2.1/...
              
とすると、"venus:1666" の "//depot2/elm2.1" パスにあるすべてのファイルが、"mars:1666" の "//depot/elm2.1" パスにあるファイルと比較されます。
image_toyo_common_spacer.gif.gif
また、自分のワークスペースを "//venus" のファイルと同期させ、"//venus" の ファイルをローカル・ディポにブランチし、"//venus" の変更をローカル・ディポに反映することができます。
image_toyo_common_spacer.gif.gif
"//venus" パスにあるファイルにアクセスする際、p4は "venus:1666" のPERFORCEサーバとは直接通信していません。 その代わり、p4(またはP4Win)プログラムが "mars:1666" のPERFORCEサーバと通信し、 そのサーバが今度は "venus:1666" のPERFORCEサーバに通信しています。
image_toyo_common_spacer.gif.gif
image_toyo_ss_img_all_line_dot_526.gif.gif
image_toyo_common_spacer.gif.gif
リモート・ディポの制限

image_toyo_common_spacer.gif.gif
アクセスは読み取り専用です。リモート・ディポ・アクセスは、読み取り専用の操作に制限されます。 ファイルをリモート・ディポにサブミットすることはできません。リモート・ディポのファイルを 編集することもできません。しかし、リモート・ディポにあるファイルからローカル・ディポに ブランチを作成した後、リモート・ディポの変更をローカルのブランチに反映することは可能です。 このことは、サードパーティの開発者と共同で作業するときなど、コードの変更箇所および変更時期を 管理したい場合には有益です。
image_toyo_common_spacer.gif.gif
サーバのバージョンがリモート・ディポの動作を決定します。サーバ・バージョンが99.2以降である場合、 リモート・ディポはUNIXとWindowsとの間での相互運用が可能です。バージョンが98.2以降である場合、 リモート・ディポは(98.2以降の)リリース間での相互運用が可能です。バージョンが98.1以前の場合は、 リモート・ディポは同じリリースの別のPERFORCEサーバに対してのみ動作します。
image_toyo_common_spacer.gif.gif
ライセンス認証の必要条件:リモート・ディポにアクセスするために新たなライセンスは必要ありません。
image_toyo_common_spacer.gif.gif
メタデータ・アクセス非対応:PERFORCEサーバのメタデータ(クライアント・ワークスペース、チェンジリスト、 ラベルなどの情報)には、リモート・ディポを使用してアクセスできません。p4 client などのコマンドは常に、 ローカルのPERFORCEサーバのメタデータに定義されたエンティティの仕様を返します。またこのことは、 サードパーティとコードを共有する際に便利であり、企業の内部情報が見られることを防止します。
image_toyo_common_spacer.gif.gif
ファイル・リビジョンの参照:リモート・ディポにあるファイルはリビジョン番号またはチェンジリスト番号に よって指定が可能ですが、チェンジリスト番号で指定されると、ローカルPERFORCEサーバではなくリモート PERFORCEサーバのチェンジリスト番号が使用されます。リモート・ディポのファイルへはラベル名または クライアント名によってアクセス可能ですが、これらの場合にはローカルPERFORCEサーバのラベルと クライアント仕様が使用されます。
image_toyo_common_spacer.gif.gif
片側だけの反映レコード:PERFORCEサーバはそれぞれ独自のメタデータのみを参照するため、 別のインストールにあるディポ間の反映に関する知識は非常に限定的です。例を示します。
image_toyo_common_spacer.gif.gif
"mars:1666" ディポのどこかにある "m_foo.c#15" ファイルが、"venus:1666" ディポの どこかにある "v_foo.c#1" にブランチされている。
ローカル・ユーザが "venus:1666" ファイルを変更し、それが "v_foo.c#2" になっている。
"mars:1666" のユーザが "v_foo.c" から "m_foo.c" へと反映を行った。 これで "m_foo.c#16" には "v_foo.c#2" のデルタが含まれている。
"venus:1666" の別のユーザが "m_foo.c" から "v_foo.c" へと反映を行った。 しかし、"venus:1666" PERFORCEサーバは "mars:1666" のめたデータを見ることができないため、 "m_foo.c#16" デルタが "v_foo.c#2" から来ていることを認識しない。認識しているのは、 最後の反映が "m_foo.c#15" から実行されていることのみである。 そのため、"m_foo.c#16" から "v_foo.c" への不必要な反映を計画してしまった。

image_toyo_common_spacer.gif.gif
パフォーマンス:リモート・アクセスによって、ローカルのパフォーマンスが極度に低下することがあります。 リモートPERFORCEサーバへのアクセス速度が非常に遅い場合、ローカル・ユーザは接続が確立されデータが 戻されるまで停止状態になります。p4 protect コマンドを使用して一般ユーザからリモート・ディポを保護し、 減速が起きる場合があることを理解している特定のユーザだけがアクセスできるよう制限することが最善の策です。
image_toyo_common_spacer.gif.gif
image_toyo_ss_img_all_line_dot_526.gif.gif
image_toyo_common_spacer.gif.gif
結論および推奨事項
image_toyo_common_spacer.gif.gif
可能な限り、分散された開発プロジェクトには単一のPERFORCEインストールを使用してください。 PERFORCEはリモート・ユーザをサポートするように設計されています。地理的に離れた場所にいるユーザが 実際に同じ開発プロジェクトに従事している場合、彼らのコードはすべて、1つのPERFORCEサーバによって 管理されているディポの中に置くべきです。共同開発プロジェクトを別々のPERFORCEインストールに分割しようと すると、スループットが改善されず、通常は管理が複雑になるだけです。さらに、ネットワークが非常に遅いために、 敏捷で受動的なクライアント/サーバ・アプリケーションであるPERFORCEによってさえ共同開発における問題が 解決できないのであれば、いかなるリモートまたは複数サイトの実装をもってしても、単にネットワークを アップグレードしたとき以上に生産性を向上させることはできないでしょう。
image_toyo_common_spacer.gif.gif
リモート・ディポを使用して、進行中の作業を他の組織からインポートしてください。 グループBがグループAのプロジェクトの開発に貢献していない場合でも、グループBがグループAの最新の コードにアクセスする必要があることがあります。このような場合も想定して、組織と組織との間において、 開発ではなくコードを共有するために、リモート・ディポ・サポートは設計されています。
image_toyo_common_spacer.gif.gif
クライアント・ビューおよびアクセス権限を制限してください。インストールに多くのユーザおよび/または 多くのディポ・ファイルがある場合、接続している各ユーザのファイル・ビューを制限することによって、 PERFORCE サーバの応答時間を最適化できます。リモート・ディポを使用する場合は、制限されたディポ・ビューと 共に制限されたクライアント・ビューおよびアクセス権限を使用して、リモート・ディポ検索のローカル・ユーザへの 影響を減少させてください。ユーザは、実際に作業しているディポ・ファイルにビューを制限するように、 自分のクライアント仕様を調整することができます。PERFORCEスーパーユーザは、プロテクションを使用して、 ディポ・ファイルへのユーザ・アクセスを制限することができます。
image_toyo_common_spacer.gif.gif

 
image_toyo_ss_img_all_btn_yellow_bgwhite2.gif.gif戻る

detail__vid--text.png

はい (0)
いいえ (0)

PAGE TOP

本ウェブサイトではサイト利用の利便性向上のために「クッキー」と呼ばれる技術を使用しています。サイトの閲覧を続行されるには、クッキーの使用に同意いただきますようお願いいたします。詳しくはプライバシーポリシーをご覧ください。