[p4] Question about locking branches
jab
jab at pobox.com
Tue Oct 5 19:04:17 PDT 2004
On Oct 5, 2004, at 5:44 PM, Grills, Jeff wrote:
> If your intent with locking a branch is simply to keep people from
> submitting to the branch, but you don't care if they "p4 edit" files,
> then I'd suggest a pre-submit trigger to fail the check in. We do
> something based off this technique here when we have a branch that is
> getting close to release to control the changes that go in at the 11th
> hour.
Don't forget that there's four permissions to play with, not three:
list - ability to see its filename using "p4 files ..."
read - ability to see its contents via "p4 print" and "p4 sync"
open - permission to open-for-edit, open-for-delete, and
so on. I call it, "permission to experiment but not submit."
(People forget this permission, but it's handy.)
write - permission to submit a new revision to a file, which
includes permission to create a new filename (revision 1)
and permission to delete (check a 'delete' revision)
I've intentionally left out any "undoc" permissions and any
administrator
permissions, to keep this simple.
For "patch/release" lines, you might consider taking away write
and then adding, in a subsequence line, permission to experiment:
write user * * -//depot/release20.21/...
open group dev * //depot/release20.21/...
(Even if you find an 'undoc' way to just yank 'write' permission, this
is supported officially.)
Then people can experiment with bug fixes, emailing "p4 diff" output
around, and when they get permission, you give 'em write permission
for long enough to check in the patch code. (Or some similar thing that
isn't as manual. You decide - it's *your* process.)
-Jeff Bowles
Perforce Consulting Partner
ps. While we're at it, Patrick, that unanchored expression in your
"p4 protect" table (//depot/.../something/...) might eventually eat
some
CPU time on your server if you have many files stored in Perforce.
It's probably not a big deal, but keep that construct in mind as your
server grows. Over time, you might eventually shy away from it.
More information about the perforce-user
mailing list