[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
(In general, "code freeze" can be a time-waster for files that are
[somewhat] easily put through an automatic or semi-automatic merge process.)
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
> 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.
> perforce-user mailing list - perforce-user at perforce.com
Jeff Bowles - jeff.a.bowles at gmail.com
More information about the perforce-user