[p4] User initiated Codeline Freezes

Jeff A. Bowles jab at pobox.com
Sat Aug 25 15:41:48 PDT 2007

I think that I would try to finesse this into a different, more manageable

If you are trying to keep updates from happening on a release that is NEAR
the end-point of development/testing, perhaps that is the moment to branch
into a different tree.  Then control access to that release-branch ("dev
project leads only" or the like can make/edit the branch) until release,
then lock the release tree down completely until a patch is requested.

No one is enjoined from checkins -- which is what a "code freeze" causes and
that's a waste of dev time -- in the main/normal/trunk area.

Then you can spend a small amount of quality time writing 2-3 small, very
special-purpose scripts for the Dev project leads to run to create the
release branch.  One would create a release-branch "branch specification"
and save it; a second would "populate-not-submit" a release tree from a
label, date, or changelist number and construct the pending changelist (and
check-in description) to your needs. (Its last line of output would be,
"when you are satisfied with this, run 'p4 submit -c 1235' (or whatever).")

Those scripts could be on a web-based tool or run from whatever workspace
you want.

(In general, "code freeze" can be a time-waster  for files that are
[somewhat] easily put through an automatic or semi-automatic merge process.)

    -Jeff Bowles

On 8/24/07, Jason Williams <streak at narus.com> wrote:
> Scott Marshall wrote:
> > Hi all,
> >
> > Does any one have any ideas about how to offer a
> > tool/script that p4 users could execute to essentially
> > "freeze" a code line? I know that I can change
> > permissions in the protect table but that requires admin
> > access and I don't want to have keep changing this
> > whenever someone wants to lock a branch. I guess there
> > are triggers that could be employed but what would be the
> > best way to flag that the branch is locked vs unlocked?
> >
> > Any insights would be appreciated.
> We handle this by having a web-based tool wrapped around the groups
> functionality.
> The tool allows managers of a code line to control who can check in to a
> code line.
> The code lines are defined in the protection table.  I've always wanted
> to extend it to use a trigger so more helpful error messages can be
> returned.  The default error message when someone can't submit a file to
> a locked code line ("no permission to lock file") can be rather confusing.
> --Jason
> _______________________________________________
> 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

More information about the perforce-user mailing list