[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