views:

246

answers:

3

In a perforce depot I have an area containing stable branches, and an area containing unstable branches. I want to control a users ability to create new branches (using p4 integrate) within the stable area. So for example my depot is laid out like so:

//depot
       /stable
              stable_branch_1/...
              stable_branch_2/...
              ... (I want users to be stopped from integrating to here)
       /unstable
              unstable_branch_1/...
              unstable_branch_2/...
              ... (I want users to be able to integrate to here)

I'm aware that in the p4 permissions I can set something like:

=branch     user     *         * -//depot/stable/...

(c.f.) but this is the exact opposite of what I need (i.e. bans users from using stable as a source for integrations, rather than a target).

I'm very surprised that it doesn't seem possible to do what I want without resorting to using triggers, can anyone provide any suggestions?

Edit: Just to make clear I wan't users to continue to be able to write to the stable folder, I just want to prevent an integrate operation being performed with the stable folder as a target.

+2  A: 

Ok,
combining the collective wisdom here and from our Perforce admin, I'd suggest the following:

write    user    *    *    -//depot/stable/...
write    user    *    *     //depot/stable/existing/branchA
write    user    *    *     //depot/stable/existing/branchB

i.e. take away write-rights from the stable-depot and then re-grant it again. Also, it is important to note the difference between =write and write. The first one grants exactly write-rights (and nothing else, no read, no sync, no nothing), the latter one grants write-rights and all lower level rights (e.g. read, sync).

jhwist
Apologies, I didnt make that point in the post itself, I want users to be able to check in to existing branches, just not to be able to create new ones. I tried perforce support and they said it wasn't supported, I just thought I'd reach out here and ask because it seems like a strange omission.
nfg
+2  A: 

If you set explicit permissions on each subbranch in your stable area you should be able to give users full access to existing branches/projects you have created, but they will be unable to create new brances/projects

eg. In your permissions file (I dont know the syntax and dont have perforce on this machine)

#  Do not give any permissions for  //depot/stable
write    user_group    *    *    //depot/stable/stable_Branch_1/...
write    user_group    *    *    //depot/stable/stable_Branch_2/...
write    user_group    *    *    //depot/stable/stable_Branch_3/...

etc

Your users should now not be able to create any new branches/projects/folders at the //depot/stable/... level but have full permissions above. You cant prevent them from integrating into the existing branches though. That I'm afraid involves user education!

Toby Allen
+1 for that, I think, depending on the rest of the protection file, it would be necessary to explicitly take away write-rights to the //deport/stable path and then re-grant them to the specific paths.
jhwist
+2  A: 

Adding this to your protections table will prevent the user from integrating into //depot/stable while still allowing them to integrate from it:

=write user * * -//depot/stable/...

Remember, order is important. Perforce applies the permissions in the order that they are listed. This...

=write user * * -//depot/stable/...
write user * * //...

...is no different than this:

write user * * //...

Also, Perforce throws a rather unintuitive error when a denied user attempts to integrate into the forbidden area. Instead of saying something sensible like, "You do not have permission to write to this folder", it pops up this nonsense:

alt text

raven

related questions