[p4] How to restrict general users from creating any branch?

Tue Sep 5 07:50:38 PDT 2006

You can use the triggers on form-save to prevent users from creating a
branch spec. And, you can use the Perforce Protect table to limit a
user's accessibility to particular directories. For example, if I have
this:

	  write group dev * //depot/Foo/...

Users in group "dev" can get access to branch MAIN, and create other
branches under project Foo. If I do this:

        read group dev * //depot/Foo/...
	  write group dev * //depot/Foo/MAIN/...
	  write group dev * //depot/Foo/REL_1.0/...

Users in group "dev" only have write access to branches REL_1.0 and
MAIN. They can't create a branch //depot/Foo/REL_2.0.

Probably the best way is trigger the form on the "p4 submit" command.
Parse the files on the changelist being submitted, and make sure the
file's directory already exists in the depot. If the file's directory
doesn't exist, examine the file via the "p4 -ztag opened" command and
examine the "action" field. If it says "branched", a new branch is being
created. If it is something like "add", then the file is being created.

The problem is that the "p4 integrate" command is used for not just
branching and merging (which the above trigger will work), but also for
copying and moving. Plus, there is no real difference between a "branch"
in Perforce and a "directory". For example, imagine the user doing
something like this:

    $ p4 integrate ./*.jpg ./images/*
    $ p4 delete ./*.jpg

(NOTE: I know this isn't 100% valid, but it's just to make my point). As
you can see from the commands, the user has decided to move all the JPEG
files out of the current directory and move them over to the "image"
directory. Now, the user submits the changes, and hits your trigger. The
directory "images" is a new directory, and if I look at the output of
the "p4 -ztag opened" command, it will tell me that it's a branch. Your
trigger will prevent me from submitting my changes even though I am not
really branching.

Of course, when you construct a wall, users will start looking for ways
to get through the wall:

   $ p4 integrate ../MAIN/* ../FOO/*
   $ p4 submit  #Your trigger will fail this
   $ p4 revert //...
   $ cp ../MAIN/* ../FOO/*
   $ cd ../FOO
   $ p4 add *
   $ p4 submit  #Now, I can "branch"

Or even better:

   $ p4 add ../FOO/fakefile.txt
   $ p4 submit
   $ p4 integrate ../MAIN/... ../FOO/...
   $ p4 delete ../FOO/fakefile.txt
   $ p4 submit  #This submit works

Which really brings up a CM philosophy question. There are two ways of
handling CM work. One is known as "fascist" mode. It tries to enforce
policy by implementing rules and triggers. Users will become frustrated
and may simply find ways of getting around these triggers. The
development environment becomes a contest of wills between developers
and the CM.

The other way is what I call the "Benevolent God Mode". The CM is like
an all seeing God who rewards the good and punishes the wicked even
until the third generation. Remember that in a good CM system like
Perforce you know who did what -- nothing escapes your all seeing
omnipotent eye. Someone who violates policy can easily be tracked down
and zapped with a lighting bolt. Plus, you can use the "p4 obliterate"
command to undo the evil.

Instead of making a trigger that prevents users from branching, make a
post-op trigger that allows a user to submit the branch, but emails you
that a user has created a new branch. You can then examine the change
list and determine whether or not the user was merely moving files
around, or they were actually branching. If they were actually
branching, you can contact the user and find out why. 90% of the time,
there probably isn't a problem.

You might also examine your policy and decide why users might want to
branch and why you want to prevent this. For example, users might want
to create a private branch in order to try a few things out. In that
case, creating a private area where users can do this will make things
much easier. Maybe users need to branch, but can't find you, and don't
want to delay work that must be done. It's one of the reasons version
control systems got away from mandatory file locking. Maybe give a few
lead developer the "permission" to create these branches. Maybe simply
tell developers to email just to let you know what is going on. Maybe
you're afraid that users might "mis-branch". In that case, create tools
that help the user create the branch. Maybe makes sure the branch is in
the correct layer of the depot directory structure and follows your
naming conventions.

Also determine whether you actually have buy in with your branching
policy. Do the managers support your policy? If you got management buy
in, then enforcing the policy is much simpler. If a developer violates
the policy, you can gather the information needed, and present it to the
manager. The manager will then back you when you confront the developer.
Its one thing for the developer to ignore you. It's another thing for
the developer to ignore a manager who has hiring and firing power over
them.

-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of - C Saha -
Sent: Monday, September 04, 2006 12:53 AM
To: perforce-user at perforce.com
Cc: p4sync at yahoo.com
Subject: [p4] How to restrict general users from creating any branch?

Hi Perforce Experts 

  I am looking to implement a trigger which will restrict the general
user from creating any branch and only suer users should be able to do
it. 

  Pls let me know if anyone has already implemented it. 

Thanks a lot to all in advance 

====================
Thanks & Regards
CSaha

---------------------------------
Want to be your own boss? Learn how on  Yahoo! Small Business. 
_______________________________________________
perforce-user mailing list  -  perforce-user at perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user