[p4] Best Practices for enforcing codeline open/closed policy?

Jay Glanville Jay.Glanville at naturalconvergence.com
Fri Mar 11 13:01:47 PST 2005

> From: perforce-user-bounces at perforce.com 
> [mailto:perforce-user-bounces at perforce.com] On Behalf Of 
> Bryan Pendleton
> Some of my users are interested in actively enforcing
> certain codeline policies. To start with, they are
> interested in ways to configure Perforce so that it
> enforces the notion of "open" and "closed" for a codeline.
> I can think of at least 3 possible ways this might be done:
>   - protections
>   - triggers
>   - additional branches
> In our particular case, codelines may "open" and "close"
> frequently (several times a day). We currently do this
> totally by convention. Violations of the policy are accidental;
> we are just looking to have Perforce help "catch us if we
> make a mistake".
> Has anybody gathered some nice guidelines or best practices
> about good ways to do this? Any pointers you can send me?

Dealing with submissions:
First, how do you want to deal with invalid (or unallowed) code
submissions?  Do you want to be preventative or reactionary?

If being reactionary (reacting to the submission), then simply use the
built in review damon (i.e.: "watch" the closed streams).  Therefore,
when someone submits to the closed stream, you get an email notification
and you react to it.

If you want to be preventative (prevent code submissions), then you need
to set up some form of triggers or protections to restrict the branches.

Restricting Branches:
In our development environment, we have three different statuses: open,
closed and restrictive

A closed stream is one that represents a version of our product that we
aren't going to release patches for any more.  To prevent code
submissions, I'd recommend using protections and make those streams
read-only.  As they're closed, they aren't going to open up again, and
thus we only need to make a single change.

A restrictive stream is where you need permission to make changes to the
code.  In this case, you need a job that's assigned to you and is
targeted for that stream (i.e.: my manager has said through the bug/job
processes that I'm to fix job XXXX in branch YYYY).  Branches like this
are usually versions of our product that have been released to the
field, or are about to be released, or have gone through a rigorous QA
process prior to being released.  Thus, management wants strict control
over the branches content.  I recommend using some form of pre-submit
trigger in this situation, one that confirms that the job id associated
to the changelist is an open job, who's target matches the branch, etc,
etc, etc.  That way, you don't need to go in an reopen a stream just to
submit a bug fix.  I.e.: codify your process.

An open stream is a free-form stream where people can submit without
restrictions.  In this situation, no triggers or protections.

So, if you're just being reactionary, simple.  If you're being
preventative, you've got a few methods open to you.

Hope this helps.


More information about the perforce-user mailing list