[p4] How to restrict general users from creating any branch?
David Faison
dfaison at photon.com
Wed Sep 6 08:10:01 PDT 2006
This feature blocks *any* integration (new or existing) of a file from a
'protected' region.
I haven't had occasion to see this behavior proven in production (and so
there may be some idiosyncratic nuances that I'm not aware of) but I ran
a simple test case and it supports the argument that *all* integration
events are blocked...
To test, I put the following in my protection table:
=branch user <me> * -//...
Then on an existing branch, I issued:
"p4 integrate -b <branch> <existing_target_file>"
I immediately saw the following response:
"- no permission for operation on file(s)."
I removed the "=branch" entry from the protection table.
I then ran the same integration command again. I no longer receive the
"no permission" message.
David
-----Original Message-----
From: Stephen Vance [mailto:steve at vance.com]
Sent: Tuesday, September 05, 2006 6:23 PM
To: Weintraub, David
Cc: David Faison; - C Saha -; perforce-user at perforce.com
Subject: Re: [p4] How to restrict general users from creating any
branch?
The "=branch" permission disallows branching (any integration where the
target does not yet exist) *from* the protected area. This would prevent
you from "merging" newly added files in the protected area to another
branch. Remember, in the end, these things happen on a per-file basis.
To disallow merging, you would have to remove write on the target of the
area. Outside of a trigger, I don't know of a way to allow edits to an
area, but not merges into it.
Steve
Weintraub, David wrote:
> Does the "=branch" permission allow merging? What if I am merging from
> MAIN to REL_1.0, and I have added new files to MAIN? Am I allowed to
> "merge" those new files, or will that be considered a new branch for
> that particular file?
>
> The branch/merge model in Perforce is a bit messy due to "interfile
> branching", Perforce not tracking directories as full depot members,
and
> the fact that merging, branching, copying, and moving files are all
done
> with the same "p4 integrate" command.
>
> -----Original Message-----
> From: David Faison [mailto:dfaison at photon.com]
> Sent: Tuesday, September 05, 2006 5:22 PM
> To: Weintraub, David; - C Saha -; perforce-user at perforce.com
> Subject: RE: [p4] How to restrict general users from creating any
> branch?
>
> There is a protection level specific to branching, and a syntax that
> lets you control it as a privilage independently of all other rights.
>
> If you type "p4 help undoc" you will see the following section:
>
> Protections =read, =branch, =open, =write
>
> In addition to the normal protection levels (list, read, write,
> open, super, and review) there are four protection rights
> available in the 'p4 protect' table. Unlike the levels, these
> '=rights' only include the specific right and not all the lesser
> rights. This makes it possible to deny individual rights without
> having to then re-grant lesser rights.
>
> Additionally, there is a new right =branch (normally included
> by level 'read' and above) that permits the files to be used as
> the source for 'p4 integrate'. You can prevent files from being
> branched by denying the =branch right.
>
> Notice that the second paragraph says "... that permits the files to
be
> used as the source for 'p4 integrate'." This feature applies to depot
> regions and restricts them from being the SOURCE of an integration.
> There is no way to use the protection table to give users read-write
> access to a region and also restrict them from branching TO that same
> region (unless of course you restrict their ability completely, not
> allowing them to integrate from anywhere).
>
> David Faison
>
> -----Original Message-----
> From: perforce-user-bounces at perforce.com
> [mailto:perforce-user-bounces at perforce.com] On Behalf Of Weintraub,
> David
> Sent: Tuesday, September 05, 2006 10:51 AM
> To: - C Saha -; perforce-user at perforce.com
> Subject: Re: [p4] How to restrict general users from creating any
> branch?
>
> 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
> _______________________________________________
> perforce-user mailing list - perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
> _______________________________________________
> perforce-user mailing list - perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>
>
More information about the perforce-user
mailing list