[p4] Limiting users ability to create new branches

[Jeff A. Bowles]

That is, well, sort of the main hassle with that strategy.
Me, I'd have a trigger that does this:

(1) "p4 describe -s" on the changelist. Might need to do "p4 opened".
     - if nothing opened for the operation of branch or integrate, the
trigger succeeds.
(2) Run "p4 resolved" to see what was merged/branched from where. (You might
need
    to run "p4 -c workspacename resolved" and even then, it's possible that
you'll have
    a hassle with client workspaces that have "Host:" specified in the spec.
Look up
    "p4 -H machinename" if necessary.)
(3) Using Perl/Python/Ruby but not Unix shell/DOS ".bat" files, compare the
two
     lists: files that are being branched/integrated and the "resolved"
output. This will allow you
     to definitively know what is being branched from where, and to where.
     - For each of the files being branched/integrated, compare against a
master list
     or template. I would hard-code it for the first draft of the script,
perhaps table-driven
     but not too sophisticated: "main to release/1.0 is okay, the other
direction is okay".
     Perhaps even wildcards that you can recognize in your Perl/Python/Ruby
script,
     such as "//depot/main/.*" to "//depot/releases/\d\.\d/.*" is okay.
     - Do not forget that main->main and releases/1.0 -> releases/1.0 (and
so on) is
     okay, which takes care of renames within branches but forbids them
outside of
     branches.

This way, you'd have a list of "acceptable" paths for data to be integrated
that is enforced by a trigger: "from codeline main to A is okay but A-to-B
is not" would be enforced, and renames would stay acceptable.

I wrote one of these scripts, a great while back.  (Where did I put that
thing? I thought it was the public depot. Oh, well.)

Count the number of calls to "p4" in the trigger. In this case, it is
perhaps 3 or 4 calls, total. (Note that it's a constant number, regardless
of the number of files in the changelist. That's important for performance
of the trigger and also for performance of the server.)

  -Jeff Bowles

On Fri, Feb 29, 2008 at 11:32 PM, Nittin chawala <nittinchawala at yahoo.co.in>
wrote:

> How would you differentiate if someone is branching or renaming/moving
> files around because use has to use "p4 integ" for this purpose also ?
>
>  --
>
> Robert Cowham <robert at vaccaperna.co.uk> wrote:
>  As well as protections, you can use a pre-submit trigger to check on
> newly
> branched files and their locations.
>
> For example:
>
>
> http://public.perforce.com/guest/robert_cowham/perforce/utils/triggers/index
> .html<http://public.perforce.com/guest/robert_cowham/perforce/utils/triggers/index.html>
>
> There are a couple of examples which ensure that people at least name
> their
> branches in accordance with certain standards. Keeps the namespace clean
> and
> tidy and prevents typos etc.
>
> There is also the pro-active education side of things to find out why they
> are creating so many, to show some of the issues and to educate them as to
> the error of their ways. The latter can, on occasion, be helped by
> application of said baseball bat :)
>
> > -----Original Messag-----
> > From: perforce-user-bounces at perforce.com
> > [mailto:perforce-user-bounces at perforce.com] On Behalf Of
> > Jamison, Shawn
> > Sent: 27 February 2008 14:22
> > To: perforce-user at perforce.com
> > Subject: [p4] Limiting users ability to create new branches
> >
> > I have the express need to limit a development groups ability
> > to create new branches.
> >
> > They seem to think that a new branch is the solution to every
> > development problem.
> >
> >
> > Has anyone experienced this before or have any suggestions on
> > how to accomplish this?
> > Besides sending a dude named Tony to visit them with at
> > baseball bat...
> _______________________________________________
> perforce-user mailing list - perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>
>
>
> ---------------------------------
>  Now you can chat without downloading messenger. Click here to know how.
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>



-- 
---
Jeff Bowles - jeff.a.bowles at gmail.com