Branch lock in perforce?

Question

Currently, after creating the release branch, but when we have time before we release, I sometimes open the entire branch for editing and then lock all the files so that no one can change anything during the “freeze” period of the release .

Is there a better way? Doing this of my current method seems to be possibly using the lock function incorrectly, is there a better way to keep someone from checking the code without using branches. Although I protect from P4, I’m not the administrator of this instance of perforce, and working with the protection file in potentially 100 lines is also cumbersome.

Any ideas?

Answer 1

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

However, in my organization I cannot be an administrator, so for this you need to have a script trigger in perforce that reads a text file that non-admins have write access to, and checks if the branch appears in the list, Thus, administrator access. such as p4 protection, not needed.

Answer 2

I do this all the time as an assembly engineer. I use p4 protection to restrict all users to read-only trees:

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 in the branch (provided that the "all" group is correctly defined.)

The second line re-sets read permissions for everyone.

The last line re-sets all permissions just for me.

Answer 3

p4 protect is by far the best way to go - that's what it is for. I highly recommend that you put all your users in groups, and only ever use groups in your protection table - much easier to manage.

You can protect any level of detail that you like, so it's not bulky. Also note that server version 2008.1 has a new security feature that allows you to specify what you can do slightly differently. 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 a problem with being an administrator in order to lock and unlock this, you should take a look at the "group owner" feature introduced in 2007 .3. This will allow the non-superuser to add and remove people from the group. Therefore combine this with the protection table. That is, get the site administrator to configure the protection table and restrict the rights of the group named "Rel 1.0 Authorized" and make you the owner of the group. Then you can add and remove users (or subgroups) from this group to control access.

The trigger option is an option, but you still need to be an administrator to configure the trigger in the first place. You can also affect the performance of all views, which you can pay attention to. But the main problem with triggers is that you will use them to emulate the built-in function designed for this purpose, i.e. Protection tables. And, if you want to be safe, you still need to find a way to prevent someone else modifying the link file. It just seems like you need to work hard to imitate an existing function.

Answer 4

As a small addition to one of the other answers. First, configure the "everyone" group, in which there are all users. Then add this to protect p4

 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 of "1.0" into which you can add all 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 write access (do not read and list) from each group.

Answer 5

The way to do this in modern Perforce is to use streams with names that are updated on your local system and may have permissions to encourage you to do the right thing when merging and copying between streams.

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