Perforceの管理: 保護
Perforceはディポ内のファイルに対して権限のないアクセス、または不注意によるアクセスを防ぐ保護スキームを提供します。保護スキームにより、実行できるPerforceコマンド、対象のファイル、誰が実行可能か、どのホストから実行できるかが限定されます。保護の設定はp4 protectコマンドを使って行います。
いつ保護を設定するか?
p4 protectは、Perforceを初めてインストールした直後に実行してください。p4
protectを実行するまでは、すべてのPerforceユーザはスーパーユーザであり、ディポ内のすべてにアクセスしてそれらを変更することができます。ユーザがp4
protectを初めて実行すると、保護テーブルが作成され、すべてのIPアドレスからのスーパーユーザのアクセス権をそのユーザに提供し、その他のユーザのアクセスレベルをすべてのIPアドレスからの全ファイルに対するwriteアクセス権に下げます。
Perforce保護テーブルは、サーバルートディレクトリのdb.protectファイルに保存されます。p4 protectが権限のないユーザによって最初に実行された場合、このファイルを削除すればディポを保護されていない状態に戻すことができます。
p4 protectによる保護を設定する
p4 protectのフォームは、Protections:という複数行から成る単一のフォームフィールドで構成されています。Protections:の各行には、下図のようにサブフィールドが設けられています。
Example 5. 保護テーブルの例
Protections:
read user emily * //depot/elm_proj/...
write group devgrp * //...
write user * 192.168.41.0/24 -//...
write user * [2001:db8:1:2::]/64 -//...
write user joe * -//...
write user lisag * -//depot/...
write user lisag * //depot/doc/...
super user edk * //...
(実際に表示される5つのサブフィールドは、縦の列が揃っていないことがあります。見やすくするために、ここでは縦列が揃えられています）
Note
サイトでPerforceプロキシを使用している場合は、ホストフィールドのアドレスの先頭にproxy-を追加して、当該プロキシのユーザに各行が適用されるようにしてください。詳細情報は、『Perforceサーバ管理者ガイド: マルチサイト展開』の「P4Pと保護」を参照してください。
権限の行の5つのフィールド
各行で、個々の権限レベルまたはアクセス権限が、以下の5つのフィールドによって定義されます。
|
フィールド |
意味 |
|---|---|
|
|
認めるかあるいは拒否するアクセスレベル( 一般的に、ユーザまたはグループごとにアクセスレベルが1つ与えられます。より細かい制御が必要であれば、1つ以上の特定の権限を拒否することができます。 |
|
|
保護の対象が |
|
|
その行の保護レベルが定義されているユーザまたはグループの名前を記述します。このフィールドではワイルドカード |
|
|
アクセスが許可されているホストのTCP/IPアドレスを記述します。特定のホスト(例えば、
ホストフィールドではワイルドカード
プロキシマッチングを制御する場合の行頭以外では、ワイルドカード PerforceプロキシによるPerforceサーバーへのアクセスの制御について詳しくは、『Perforceサーバ管理者ガイド: マルチサイト展開』の関連する章を参照してください。 |
|
|
権限を付与するディポのファイル仕様を指定します。指定には、Perforceのワイルドカードも使用できます。
「 ディポが除外された場合、アクセスを拒否されたユーザはp4 depotsの出力でディポを見ることができなくなります。また、このユーザに対してデフォルトのブランチビュー、クライアントビュー、ラベルビューでディポは表示されません。 |
アクセスレベル
アクセスレベルは各行の先頭に記述されます。権限レベルおよびアクセス権限を以下に示します。
|
レベル |
意味 |
|---|---|
|
|
p4 filelogなど、ファイルのメタデータを表示するPerforceコマンドの実行が認められます。ファイルの内容を参照または変更することは認められません。 |
|
|
p4 client、p4 syncなど、ファイルの読み取りに必要なPerforceコマンドの実行が認められます。 |
|
|
この権限が拒否されている場合、ユーザはファイルに対してp4 print、p4 diff、p4 syncを使用できません。 |
|
|
ディポからクライアントワークスペースへのファイルの読み込みと、それを開いて編集することが認められます。ただし、この権限では書き込みをしてファイルをディポに戻すことは認められていません。
|
|
|
この権限が拒否されている場合、ユーザはp4 add、p4 edit、p4 delete、p4 integrateを使用してファイルを開くことはできません。 |
|
|
ファイルを編集、削除、追加するコマンドの実行が認められます。
この権限は、 |
|
|
この権限が拒否されている場合、ユーザは開いているファイルをサブミットできません。 |
|
|
この権限が拒否されている場合、ユーザはp4 integrateのソースとしてファイルを使用できません。 |
|
|
レビューdaemonに使用される特殊な権限です。この権限には、listとreadのアクセス権のほか、p4 reviewコマンドの使用も認められます。このコマンドはレビューdaemonにのみ必要です。 |
|
|
Perforce管理者用です。メタデータに影響するPerforceコマンドの実行が認められますが、サーバの動作にかかわるものは認められません。 |
|
|
Perforceスーパーユーザ用です。すべてのPerforceコマンドの実行が認められます。 |
各Perforceコマンドには、最低限必要なアクセスレベルが設定されています。例えば、あるファイルにp4 syncまたはp4
printを実行するには、ユーザは少なくともそのファイルへのreadのアクセス権を認められていなければなりません。各Perforceコマンドの実行に最低限必要なアクセスレベルの全リストについては、保護の実装のしくみを参照してください。
特殊な権限である=read、=open、=write、=branchを使用して、下位のアクセスレベルを自動的に包含しないようにオーバーライドできます。これにより、個々の権限を無効にすることができます。後で下位の権限を再度付与する必要はありません。
例えば、管理者に管理コマンドの実行権限を与えつつ、ディポの特定の部分に対する変更権限を拒否したいという場合、権限テーブルを次のように設定することができます。
admin user joe * //... =write user joe * -//depot/build/... =open user joe * -//depot/build/...
この例では、ユーザjoeは管理機能を実行でき、この権限はシステム内のすべてのディポに適用されます。admin権限レベルでは暗黙的にそれより下位にあるすべてのアクセスレベルが認められるため、joeは//depot/build/を含むシステム内のどのファイルにも、書き込み、開く、読み取り、一覧表示の操作が可能です。buildの階層を保護するには、=writeおよび=openの排他行をテーブルに追加します。ユーザjoeは、build階層にあるすべてのファイルを編集目的で開くことができなくなります。また、すでに開いている可能性のある、この階層で加えられた変更はサブミットすることができません。ファイルの作成および変更は引き続き可能ですが、保護された階層//depot/build/...の外にそれらのファイルがある場合に限られます。
デフォルトの保護
p4 protectが呼び出されるまでは全ユーザがスーパーユーザの特権をもっています。p4 protectが最初に実行される以前に、デフォルトで2つのパーミッションが設定されています。デフォルトの保護テーブルは次のように表示されます。
write user * * //... super user edk * //...
これは、全ホストの全ユーザに全ファイルへのwriteアクセス権を認め、最初にp4 protectを呼び出したユーザ(この場合はedk)にスーパーユーザの特権を認めることを示しています。
各ユーザに認める権限を決める
最も単純なアクセスレベルの割り当て方は、Perforceシステムを管理する必要のないユーザ全員にwriteのアクセス権、管理するユーザにsuperのアクセス権を与える方法ですが、このような単純な方法では不十分な場合があります。
個々のファイルについて編集する必要のないユーザに関しては、特定ファイルに対するReadのアクセス権を認める方が望ましいでしょう。例えば、エンジニアなら、ソースファイルに対するwrite権限はあっても、文書ファイルに対しては、readアクセス権だけで十分な場合があります。また、コードを扱わないマネージャもすべてのファイルについてreadアクセス権で充分な場合があります。
openのアクセス権はファイルのローカル編集を可能にしますが、書き込みとディポへのサブミットは認めないので、特殊な状況でのみopenアクセス権を指定します。ユーザがローカルで変更をテストしても、その変更を他のユーザに見せる必要がない場合には、openアクセス権ではなくwriteアクセス権を与えます。例えば、バグのテスターは特定のバグが発生する理由についての理論をテストするためにコードを変更したい場合がありますが、そのような変更はディポに書き込まれるべきではありません。大抵の場合、コードラインはそのままにしておき、開発チームによる入念なレビューを経て初めてローカルの変更はディポにサブミットされます。このような場合には、コード変更が承認されるまではopenアクセス権にしておき、承認後に保護レベルをwriteに上げ、変更がサブミットされるようにします。
権限の行が重複する場合の解釈
ユーザへのアクセス権限は、ユーザ名とクライアントIPアドレスが合致する保護行のマッピングの組み合わせにより定義されます。(排他的保護が使用されている場合、この挙動は若干異なりますが、これについては次のセクションで説明します)。
Example 6. 重複する権限の行
ライザはPerforceユーザ名lisagで、IPアドレス195.42.39.17のワークステーションを使用しています。保護ファイルが次のように表示されたとします。
read user * 195.42.39.17 //... write user lisag 195.42.39.17 //depot/elm_proj/doc/... read user lisag * //... super user edk * //...
このとき、ライザには最初の3行の権限の組み合わせが適用されます。ユーザ名はlisagで、現在1行目と2行目で指定されたホストのクライアントワークスペースを使用しているため、ディポのサブディレクトリelm_proj/docのファイルには書き込みできますが、他のファイルは読み取ることができません。ライザは以下を試みます。
p4 edit depot/elm_proj/doc/elm-help.1と入力して、受け付けられます。
p4 edit //depot/elm_proj/READ.MEと入力すると、正規のパーミッションがないと返されます。これはreadアクセス権しかないファイルに書き込みをしようとしているためです。p4 sync depot/elm_proj/READ.MEと入力すれば、受け付けられます。必要なのはreadのアクセス権だけで、これは1行目で認められているからです。
ライザはさらにIPアドレス195.42.39.13の別のマシンに乗り換えます。p4 edit
//depot/elm_proj/doc/elm-help.1と入力すると、拒否されます。これは、このホスト使用中には3行目の権限しか該当しないので、readの権限しか持たないためです。
排他的保護
権限の行の5番目のフィールドの先頭にマイナス(-)を記述すれば、ユーザのアクセスを拒否することができます。これは特定のファイルへのアクセスを大半のユーザに認めながら、ごく一部のユーザがそのファイルにアクセスするのを拒否するような場合に役立ちます。
排他的マッピングを正しく活用するには、次のような特性を理解する必要があります。
-
保護テーブルの中に排他的保護が含まれている場合には、上下の順番が意味を持ちます。排他的保護は、テーブル内のその行より上の該当する保護をすべて無効にします。
-
排他的保護にどのようなアクセスレベルが指定されていても、該当するファイルおよびIPアドレスに関するすべてのアクセスが拒否されます。排他的保護で指定されるアクセスレベルは意味を持ちません。詳細説明は、保護の実装のしくみを参照してください。
Example 7. 排他的保護
管理者がp4 protectを用いて次のように保護を設定しました。
write user * * //... read user emily * //depot/elm_proj/... super user joe * -//... list user lisag * -//... write user lisag * //depot/elm_proj/doc/...
1行目は一見、全ユーザに全ディポの全ファイルへのwriteのアクセス権を認めているようですが、下の排他的保護によって、一部のユーザは除外されています。
3行目の権限はジョーについて、どのホストからのどのファイルへのアクセスも拒否します。それ以下の行でもジョーには何らのアクセスも認められていません。このため、ジョーは実質的にあらゆるファイルへのアクセスを拒否されていることになります。
4行目の権限はライザの全ホストからの全ファイルへの全アクセスを禁じていますが、5行目によって彼女には特定ディレクトリの全ファイルへのwriteアクセス権が認められます。もし4行目と5行目が入れ替わると、ライザはPerforceのどのコマンドも実行できなくなります。
ユーザまたはファイルに適用される行を知る
p4 protectsコマンドを使用して、ユーザやグループまたはファイルセットに適用される保護テーブルの行を表示することができます。
オプションを指定しない場合、p4 protectsは現在のユーザに適用される保護テーブル内の行を表示します。file引数が指定された場合、該当ファイルに適用される保護テーブル内の行のみが表示されます。-mフラグを使用すると、排他的マッピングを無視したうえで、適用可能な最大アクセスレベルの概要が一語で表示されます。
Perforceスーパーユーザはp4 protects -aを使用して全ユーザの行を表示したり、p4 protects -u
user、-g
、またはgroup-h
の各フラグを使用して特定のユーザ、グループ、ホストIPアドレスの行を表示したりすることができます。
host
ユーザのグループにアクセス権を設定する
Perforceグループは保護テーブルの管理を容易にします。同一のアクセス権限を必要とするユーザの名前を1つのグループに保存できます。その上で、そのグループ名をテーブルに記述すれば、そのグループのユーザ全員が指定の権限をもちます。
グループはp4 groupで管理し、保護はp4 protectで割り当てます。これらのコマンドは、Perforceスーパーユーザのみが使えます(Perforce管理者もp4 group -Aを使用してグループを管理できますが、グループが既に存在していない場合に限られます)。
グループの作成と編集
p4 group groupnameで、存在しないgroupnameを使って呼び出すと、groupnameのついた新しいグループが作成されます。p4 groupを既存のgroupnameで呼び出すと、そのグループのユーザリストの編集が可能になります。
グループにユーザを追加するには、p4 group
groupnameコマンドによって生成されたフォームのUsers:フィールドにユーザ名を追加します。ユーザ名はUsers:フィールドのヘッダーの下に入力します。各ユーザ名は別々の行にインデントを付けて入力します。1つのユーザ名を多数のグループに登録しても構いません。グループの所有者は必ずしもグループのメンバーでなくても構いません。グループ所有者をグループのメンバーにするには、そのユーザIDもUsers:フィールドに追加する必要があります。
グループは個別のユーザだけでなく他のグループを含むこともできます。すでに定義済みのグループのユーザ全員を作業中のグループに追加するには、p4 groupのフォームのSubgroups:フィールドにそのグループ名を含めます。ユーザ名とグループ名は別々のネームスペースを占めるため、グループとユーザは同じ名前を持つことができます。
存在しないユーザをグループ定義に追加しても、実際にはユーザは作成されず、ライセンスも消費されません。ユーザを作成するには、p4 userコマンドを使用します。
グループと保護
p4 protectのフォームでグループを使用するときは、保護テーブルのすべての該当する行にユーザ名ではなくグループ名を指定し、行の2番目のフィールドをuserではなくgroupにします。そのグループのユーザ全員に指定の権限が認められます。
Example 8. Perforceグループにアクセス権を設定する
下の保護テーブルはグループdevgrpのメンバー全員にlist、ユーザedkにsuperのアクセス権を認めています。
list group devgrp * //... super user edk * //...
次の3つの権限の行においては、グループac1は、//ac1/...への書き込みアクセス権、//ac1/ac1_dev/...への読み取り専用アクセス権が与えられます。
write group ac1 * //ac1/... list group ac1 * -//ac1/ac1_dev/... read group ac1 * //ac1/ac1_dev/...
ユーザが複数のグループに属している場合、ある権限が他の権限をオーバーライドする場合があります。例えば、排他的マッピングを使用して、group1のメンバーに対してディポのある領域へのアクセスを拒否し、group2のメンバーに対してはディポの同じ領域へのアクセスを許可した場合、group1とgroup2の両方のメンバーであるユーザは、保護テーブル内でどちらの行が最後に記述されているかによってアクセスの可否が決まります実際にユーザに認められる権限を判断するには、保護テーブル内で該当ユーザが属するすべてのグループ名をそのユーザ名に置き換えたうえで、本章で先に説明した各種のルールに則して解釈することで可能です。
PerforceグループをLDAPグループと同期する
特定のPerforceユーザグループをそのLDAPグループと自動で同期するようにPerforceを設定できます。保護は引き続きPerforceグループのIDに基づいて(p4 protectコマンドを使用して)割り当てられます。ただし、Perforceグループに含まれるユーザはLDAPグループで設定されるメンバーに基づきます。
同期は1回づつまたは指定した間隔で実行できます。詳細については、『P4コマンドリファレンス』のp4 ldapsyncコマンドの解説を参照してください。
グループの同期を設定する前に、認証オプションの解説に従って各ユーザのLDAP認証を設定する必要があります。
Note
LDAPサーバで読み取り専用クエリの実行にログインが必要とされる場合、LDAPコンフィギュレーションにおいて、LDAP仕様のSearchBindDNフィールドとSearchPasswdフィールドに有効なバインド資格情報が含まれていなければなりません。
グループの同期を設定するには、以下のことを行います。
-
Perforce
group仕様で次のフィールドを定義します。-
LdapConfig: p4 ldapコマンドを使用して作成されるLDAPコンフィギュレーションの名前です。LDAPコンフィギュレーションではLDAP接続におけるホスト名、ポート、暗号化情報のほか、認証を行う際に
SearchBindDN、searchPasswd、GroupSearchBaseDNのフィールドをどのように使用するかが指定されています。 -
LdapSearchQuery: グループメンバーのレコードを識別するための検索クエリです。 -
LdapUserAttribute: グループメンバーのユーザIDが含まれる属性を意味します。このユーザ名がPerforceグループのユーザ名に追加されます。
-
-
Perforceグループのグループ所有者を定義します。所有者は該当するLDAPグループのメンバーでなくとも構いません。
-
p4 ldapsyncコマンドを使用して、同期するPerforceグループを指定したうえで次のようなコマンドを使用し、予想される結果を確認します。
p4 ldapsync -g -n my-perforce-group1 my-perforce-group2
p4 ldapsyncでは、LDAPコンフィギュレーションによって提供されるコンテキストを使用して検索クエリが実行され、返された結果のうちすべての定義済みの属性が収集されます。グループのメンバーリストが結果一覧として表示されます。
-
プレビュー結果に問題がなければ、p4 ldapsyncを再び実行してグループを同期します。
定期的に同期を実行するようにスケジュール設定するには、起動時にp4 ldapsyncコマンドを実行して間隔の値を指定する必要があります。詳細については、『P4コマンドリファレンス』のp4 ldapsyncコマンドの解説を参照してください。
Active Directoryと同期するおよびOpenLDAPと同期するに記載される次の例で、グループ同期を定義する2つの方法を説明します。これらの例は、別々のサーバに保存されたユーザとグループの参照に応じて、コンフィギュレーションがどのように異なるかを示しています。
-
OpenLDAPのグループレコードには、メンバーユーザIDのリストが保存されています。これらは大抵の場合Perforceユーザ名として直接使用することができます。
-
Active Directoryのグループレコードには、メンバーの完全な識別名(DN)が保存されています。またユーザレコードには、ユーザが属する各グループの完全なDNが保存されています。この例では、グループレコードを直接探すのではなく、グループへの後方参照が含まれるユーザレコードを探す必要があります。
LDAP仕様のGroupBaseDnによる違いに注意してください。Active Directoryではグループに属するユーザを探し、OpenLDAPではユーザが属するグループを探します。目的のパスはそれぞれ異なることになります。
以下の例では、両方のサーバでou=users,dc=example,dc=comのDNのもとにユーザが存在します。ここでは、cn=development,ou=groups,dc=example,dc=com.のLDAPグループの内容を反映したdevelopmentのPerforceグループを作成しています。
Active Directoryと同期する
次のように定義されるmy-ad-exampleという名前のLDAPコンフィギュレーションをサンプルとして挙げます。
Name: my-ad-example Host: ad.example.com Port: 389 Encryption: tls BindMethod: search SearchBaseDN: ou=users,dc=example,dc=com SearchFilter: (&(objectClass=user)(sAMAccountName=%user%)) SearchBindDN: cn=read-only,ou=users,dc=example,dc=com SearchPasswd: password SearchScope: subtree GroupBaseDN: ou=users,dc=example,dc=com GroupSearchScope: subtree
この場合、p4 group developmentコマンドで作成されるグループ仕様は以下のようになります。
Group: development
LdapConfig: my-ad-example
LdapSearchQuery: (&(objectClass=user)(memberOf=cn=development,ou=groups,
dc=example,dc=com))
LdapUserAttribute: sAMAccountName
Owners: super
OpenLDAPと同期する
次のように定義されるmy-openldap-exampleという名前のLDAPコンフィギュレーションをサンプルとして挙げます。
Name: my-openldap-example Host: openldap.example.com Port: 389 Encryption: tls BindMethod: search SearchBaseDN: ou=users,dc=example,dc=com SearchFilter: (&(objectClass=inetOrgPerson)(uid=%user%)) SearchBindDN: cn=read-only,ou=users,dc=example,dc=com SearchPasswd: password SearchScope: subtree GroupBaseDN: ou=groups,dc=example,dc=com GroupSearchScope: subtree
この場合、p4 group developmentコマンドで作成されるグループ仕様は以下のようになります。
Group: development LdapConfig: my-openldap-example LdapSearchQuery: (&(objectClass=posixGrooup)(cn=development)) LdapUserAttribute: memberUid Owners: super
グループを削除する
グループを削除するには、次のコマンドを使います。
p4 group -d groupname
または、p4 group
groupnameで呼び出される編集フォーム上のグループからすべてのユーザを削除することもできます。フォームを閉じるとグループが削除されます。
保護の実装のしくみ
このセクションでは、Perforceが保護スキームの実行で用いるアルゴリズムについて説明します。保護については、このセクションを読まなくても適切に使用できます。ここでは、先に説明した保護の操作の背後にあるロジックを解説します。
ファイルに対するユーザのアクセス権は以下の手順により決定されます。
-
あるコマンドを実行するのに最低限必要なアクセスレベルを決定するには、Perforceコマンドが必要とするアクセスレベルのアクセスレベルテーブルでそのコマンドを検索します。ここに記載した例では、p4 printが実行するコマンドで、そのコマンドを実行するために最低限必要なアクセスレベルは
readです。 -
Perforceは保護テーブルに対する2回の走査のうちの1回目を行います。どちらの走査でも保護テーブルを下から上へ見ていき、最初の該当行をさがします。
最初の走査はユーザがファイルの有無を知ることを許されているかどうかを判断するために行われます。この検索では、単純にユーザ名、ホストIPアドレス、およびファイルの引数が合致する最初の行をさがします。最初に見つかった一致する行が包含的な保護であれば、ユーザは少なくともファイルをlistする権限を持っているので、Perforceは2回目の走査に移ります。逆に、最初に見つかった該当する保護が排他的マッピングになっていた場合、または該当する保護が見つからないまま保護テーブルの一番上まで行った場合には、そのユーザはファイルのlist権限もなく、
File not on clientのようなメッセージが表示されます。Example 9. 保護テーブルのマッピング順を解釈する
保護テーブルが次のようになっているものとします。
write user * * //... read user edk * -//... read user edk * //depot/elm_proj/...
エドがp4 print //depot/file.cを実行すると、Perforceは保護テーブルを下から上へ検証し、最初に最終行にぶつかります。ここに指定されたファイルはエドが印刷したいファイルとは異なるため、この行は関係ありません。次に、下から2行目が検証されます。この行はエドのユーザ名、IPアドレス、印刷したいファイルと合致していますが、排他的マッピングのためエドはファイルをlistすることを許されません。
-
1回目の走査が成功したら、保護テーブルに対して2回目の走査が行われます。この走査も1回目の走査と同じですが、今回はアクセスレベルが考慮されます。
ユーザ名、IPアドレス、ファイルの引数が合致した最初の行が包含的な保護行であり、かつアクセスレベルが与えられたコマンドの実行に必要なレベル以上であれば、ユーザにはそのコマンドを実行する権限が与えられます。
ユーザ名、IPアドレス、ファイルの引数が合致した最初の行が排他的マッピングの場合、あるいは合致する行が見つからないまま保護テーブルの一番上まで行った場合には、そのユーザにはコマンド実行の権限は与えられず、次のようなメッセージが表示されます。
You don't have permission for this operation
Perforceコマンドが必要とするアクセスレベル
下の表は各コマンドの実行に最低限必要なアクセスレベルを示しています。例えば、p4 addは少なくともopenのアクセス権を必要とするため、open、write、admin、またはsuperのアクセス権があればp4 addを実行できます。
|
コマンド |
アクセスレベル |
備考 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
サブミットされたファイルの属性を設定する |
|
|
|
既存のメタデータや他のユーザのデータをオーバライドする |
|
|
|
|
|
|
|
|
|
|
|
このコマンドは特定のファイルに作用するものではありません。つまり、ユーザがディポの少なくとも1つのファイルに対してアクセス権を指定されていれば、コマンド実行の権限が付与されています。 |
|
|
|
既存のメタデータや他のユーザのデータをオーバライドする |
|
|
|
|
|
configure |
super |
|
|
コピー |
list |
ソースファイルに対する |
|
|
|
既存のカウンターの値を表示するには、ディポ内の1つ以上のファイルに対する |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
このコマンドに対する |
|
|
|
このコマンドは特定のファイルに作用するものではありません。つまり、ユーザがディポの少なくとも1つのファイルに対してアクセス権を指定されていれば、コマンド実行の権限が付与されています。 |
|
|
|
このコマンドに対する |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
このコマンドは特定のファイルに作用するものではありません。つまり、ユーザがディポの少なくとも1つのファイルに対してアクセス権を指定されていれば、コマンド実行の権限が付与されています。 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
このコマンドに対する
このコマンドに対する
|
|
|
|
このコマンドは特定のファイルに作用するものではありません。つまり、ユーザがディポの少なくとも1つのファイルに対してアクセス権を指定されていれば、コマンド実行の権限が付与されています。 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ユーザは対象ファイルの |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
このコマンドに対する
既存のメタデータや他のユーザのデータをオーバライドする |
|
|
|
このコマンドは特定のファイルに作用するものではありません。つまり、ユーザがディポの少なくとも1つのファイルに対してアクセス権を指定されていれば、コマンド実行の権限が付与されています。 |
|
|
|
このコマンドに対する |
|
|
|
|
|
|
|
既存のキーの値を表示するには、ディポ内の1つ以上のファイルに対する |
|
|
|
|
|
|
|
|
|
|
|
このコマンドは特定のファイルに作用するものではありません。つまり、ユーザがディポの少なくとも1つのファイルに対してアクセス権を指定されていれば、コマンド実行の権限が付与されています。
既存のメタデータや他のユーザのデータをオーバライドする |
|
|
|
このコマンドは特定のファイルに作用するものではありません。つまり、ユーザがディポの少なくとも1つのファイルに対してアクセス権を指定されていれば、コマンド実行の権限が付与されています。 |
|
|
|
|
|
|
|
ライセンス使用量を表示する |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
処理を終了または取り消す、あるいは引数を参照するには |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
読み取りには |
|
|
|
Perforceプロキシに接続されている必要があります。 |
|
|
|
|
|
|
|
|
|
|
|
p4
reload -fを使用して他のユーザのワークスペースとラベルを再ロードするには、 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
このコマンドは特定のファイルに作用するものではありません。つまり、ユーザがディポの少なくとも1つのファイルに対してアクセス権を指定されていれば、コマンド実行の権限が付与されています。 |
|
|
|
このコマンドは特定のファイルに作用するものではありません。つまり、ユーザがディポの少なくとも1つのファイルに対してアクセス権を指定されていれば、コマンド実行の権限が付与されています。 |
|
|
|
|
|
|
|
サーバIDを設定するには、 |
|
|
|
|
|
|
|
p4 shelve -f -dにより保留状態のファイルを強制的に削除するには、 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
このコマンドに対する |
|
|
|
p4
unload -fを使用して他のユーザのワークスペースとラベルをアンロードするには、 |
|
|
|
既存のメタデータや他のユーザのデータをオーバライドする |
|
|
|
|
|
|
|
|
|
|
|
このコマンドは特定のファイルに作用するものではありません。つまり、ユーザがディポの少なくとも1つのファイルに対してアクセス権を指定されていれば、コマンド実行の権限が付与されています。
|
|
|
|
このコマンドは特定のファイルに作用するものではありません。つまり、ユーザがディポの少なくとも1つのファイルに対してアクセス権を指定されていれば、コマンド実行の権限が付与されています。
構成可能変数 |
|
|
|
|
|
|
|
このコマンドは特定のファイルに作用するものではありません。つまり、ユーザがディポの少なくとも1つのファイルに対してアクセス権を指定されていれば、コマンド実行の権限が付与されています。 |
p4 describeなど、ファイルをリストするコマンドは、ユーザが少なくともlistのアクセス権を持つファイルのみをリストします。
一部のコマンド(例えば、事前サブミットされたチェンジリストを編集するときのp4 change)は、Perforceスーパーユーザにしか実行できない-fフラグを伴います。詳細については、-fフラグによる強制動作を参照してください。