7

現在、リリース ブランチを作成した後ですが、リリースまでの時間がある場合は、ブランチ全体を編集用に開いてから、すべてのファイルをロックして、リリース ブランチの「コード フリーズ」期間中に誰かが何かを変更できないようにすることがあります。 .

より良い方法はありますか?私の現在のやり方は、おそらくロック機能の誤った使用のように思えます。ブランチを使用せずに誰かがコードをチェックインできないようにするより良い方法はありますか? 私は P4 保護について考えましたが、私はこの perforce インスタンスの管理者ではありません。また、潜在的に数百行で保護ファイルを処理することも面倒になります。

何か案は?

4

5 に答える 5

14

私はビルドエンジニアとして常にこれを行っています。「p4 protect」を使用して、全員のツリーへのアクセスを読み取り専用に制限します。

super group everyone * -//depot/project/branch/...
read group everyone * //depot/project/branch/...
super user me * //depot/project/branch/...

最初の行は、ブランチに対するすべてのユーザーのすべての権限を閉じます (グループ 'everyone' が適切に定義されていると仮定します)。

2 行目では、すべてのユーザーの読み取りアクセス許可を再確立します。

最後の行は、すべての権限を私だけに再確立します。

于 2009-03-24T17:42:47.923 に答える
3

最新の Perforce でこれを行う方法は、ストリームを使用することです。名前付きブランチは、ローカル システム上の適切な場所で更新され、ストリーム間でマージおよびコピーするときに正しいことを行うように促すために適用される権限を持つことができます。

オプションで、ストリームの所有者のみがチェックインできるようにストリームを制限できます (また、ストリームをロックして、所有者以外の誰もそのプロパティを編集できないようにすることもできます)。http://www.perforce.com/perforce/doc.current/manuals/p4guide/chapter.codelines.html#codelines.streamsを参照してください。

于 2015-03-27T17:22:56.230 に答える
2

他の回答の1つへのわずかな追加として。最初に、すべてのユーザーを含むグループ「everyone」をセットアップします。次に、これを p4 protect に追加します

write group everyone * -//depot/project/1.0/...
read group everyone * //depot/project/1.0/...
write group 1.0 * //depot/project/1.0/...

これにより、書き込みアクセスが許可されているユーザーを追加できるグループ「1.0」を作成できます。

サーバー 2008.1 を使用している場合は、これを行うことができます。

=write group everyone * -//depot/project/1.0/...
write group 1.0 * //depot/project/1.0/...

最初の行は、グループ Everyone から書き込みアクセスのみ ( read および list ではなく) を削除します。

于 2009-10-13T09:40:49.667 に答える
2

p4 protect は間違いなくより良い方法です。それが目的です。すべてのユーザーをグループに入れ、保護テーブルでグループのみを使用することを強くお勧めします。これにより、管理がはるかに簡単になります。

好きなレベルの粒度で保護できるので、扱いにくいわけではありません。また、2008.1 サーバー リリースには、少し異なる方法で実行できることを指定できる新しい保護機能があることにも注意してください。変更点:

#152278 **
    'p4 protect' now allows specification of permission 'rights'.
    Previously, 'p4 protect' only allowed using permission levels 
    which include the specified access (ie 'read') and also all
    of its lesser permissions (ie 'read' = 'read' + 'list').
    Permission rights make it possible to deny individual rights
    without having to re-grant lesser rights.  The new 
    permission rights are '=read', '=branch', '=open',
    and '=write'. This functionality was previously undocumented,
    and is now fully supported for 2008.1

これをロックおよびロック解除するために管理者でなければならないことに本当に問題がある場合は、2007.3 で導入された「グループ所有者」機能を確認する必要があります。これにより、非スーパー ユーザーがグループにユーザーを追加および削除できるようになります。したがって、それを保護テーブルと組み合わせます。つまり、サイト管理者に保護テーブルを設定してもらい、権限を「Rel 1.0 Authorized」という名前のグループに制限し、あなたをグループ所有者にします。次に、そのグループにユーザー (またはサブグループ) を追加および削除して、アクセスを制御できます。

トリガー オプションは可能ですが、最初にトリガーを設定するには管理者である必要があります。また、すべての提出物のパフォーマンスに影響を与える可能性もあります。これには注意が必要です。しかし、トリガーの主な問題は、トリガーを使用して、その目的のために設計された組み込み機能、つまり保護テーブルをエミュレートすることです。また、安全を確保したい場合は、他の誰かが参照ファイルを変更できないようにする何らかの方法を見つける必要があります。既存の機能をエミュレートするのは大変な作業のように思えます。

于 2009-03-26T16:24:40.437 に答える
0

他の回答で説明されているように、P4 プロテクトはおそらくほとんどの人にとって正しい回答です。

ただし、私の組織では管理者になることはできないため、これを行う方法は、非管理者が書き込みアクセス権を持つテキスト ファイルを読み取り、ブランチがリストに表示されるかどうかを確認するトリガー スクリプトを実行することです。この方法では、p4 protect のような管理者アクセスは必要ありません。

于 2009-03-25T23:25:43.207 に答える