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?

From stackoverflow

• 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.

  Ville M : Do you need to be a perforce admin to do this? Also, there is just one protect file for entire depot right, doesn't it get unwieldy? One typo and the entire depot won't work right? 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

  : 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.

• 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.

• 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.

• 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.