Locking a branch in perforce?

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.

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.

These are the reasons I was trying to find an alternative to protect, but still, if it's the only way I'll go with that – Ville M Mar 24 '09 at 18:25 You do have to be an admin to change the protections (it's the definition of an admin in perforce. ) Before your changes are accepted, the file is checked for errors. I have a few hundred entries in my protections, but it tracks well with my business requirements, so it feels clean and self-evident.

– user30997 Mar 26 '09 at 20:02.

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.

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.

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.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.