CODEWITHSUNDEEP
perforce
Ville M
Ville M

Reputation: 2029

Locking a branch in perforce?

Currently after I create a release branch, but when we have some time before we release, I sometimes open the entire branch for edit and then lock all files in order to prevent anybody from modifying anything during "code-freeze" period in the release branch.

Is there a better way? Doing it my current way seems possibly like an incorrect use of the lock feature, is there a better way to keep somebody from checking in code without using branches. I though of P4 protect but I am not the admin on this perforce instance, and also dealing with the protect file at potentially 100s of lines would get cumbersome as well.

Any ideas?

Upvotes: 8

Views: 12377

Answers (5)

Tim Keating
Tim Keating

Reputation: 6641

The way to do this in modern Perforce is to use streams -- named branches that update in place on your local system, and can have permissions applied to encourage you to do the right thing when merging and copying between streams.

You can optionally restrict a stream so only the stream owner can check in (and you can lock the stream so no one but the owner can edit its properties). See http://www.perforce.com/perforce/doc.current/manuals/p4guide/chapter.codelines.html#codelines.streams

Upvotes: 3

dave
dave

Reputation: 2181

As a slight addition to one of the other answers. First set up a group "everyone" which has all users in it. Then add this to p4 protect

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

This will allow you to create a group "1.0" into which you can add any users who are allowed write access.

If you are using server 2008.1 you can do this.

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

The first line removes only the write access ( not read and list ) from the group everyone.

Upvotes: 2

Ville M
Ville M

Reputation: 2029

P4 protect is probably the right answer for most people as explained in other answers.

However in my organization I can't be the admin so way of doing this is to have a trigger script in perforce that reads a text file that non-admins have write access to and check whether branch appears on the list. This way admin access like p4 protect would need is not needed.

Upvotes: 0

Greg Whitfield
Greg Whitfield

Reputation: 5739

p4 protect is definitely the better way to go - it's what it is there for. I would strongly recommend you put all your users into groups, and only ever use groups in your protections table - much easier to manage.

You can protect at any level of granularity you like, so is not unwieldy. Note also that the 2008.1 server release has a new protect feature that allows you to specify what you can do in a slightly different way. Change note:

#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

If you really have an issue with having to be an admin to lock & unlock this, then you should take a look at the "group owner" feature introduced in 2007.3. This will let a non-super user to be able to add & remove people from a group. So combine that with the protections table. I.e. get site admin to set up the protections table, and restrict rights to a group named "Rel 1.0 Authorised", and make you the group owner. You can then add and remove users (or subgroups) from that group to control access.

The trigger option is a possibility, but you still need to be an admin to set up the trigger in the first place. You could also affect performance of all submissions, which is something to look out for. But the main issue with triggers is that you would be using them to emulate a built in feature designed for that purpose - i.e. protections table. And, if you wanted to be safe, you would still need to find some way of preventing anyone else modifying the reference file. It just seems like a lot of work to emulate an existing feature.

Upvotes: 2

Sniggerfardimungus
Sniggerfardimungus

Reputation: 11782

I'm doing this all the time as a builds engineer. I use 'p4 protect' to restrict everyone's access to the trees to read-only:

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

The first line closes all permissions for all users to the branch (assuming that the group 'everyone' is defined properly.)

The second line re-establishes read permissions for everyone.

The last line re-establishes all permissions to just me.

Upvotes: 15

Related Questions