[p4] automatically building in the latest changelist number for abuild
Nick.Barnes at pobox.com
Thu Mar 24 03:07:35 PST 2005
At 2005-03-24 00:51:45+0000, "Matthew Janulewicz" writes:
> My two cents. I've had a lot of pennies today.
> I hate writing answers that don't actually answer the question, and this
> one may open up a more philisophical question, but in my opinion, knowing
> the latest changelist is ultimately not as useful as it sounds.
> If you (or anyone) is doing any kind of branching or merging, the latest
> changelist submitted (at a particular time) doesn't necessarily indicate
> what level the code is at. We've had situations where a lot of code was
> checked in, but suddenly marketing decided they only want these two
> specific changes in the next product.
> In this situation, there are two things you can do (at least.)
> 1. If your engineers check into the same branch you build from, you may
> have to sync to the latest at some time, PLUS changelist XX and XX. Just
> knowing a latest changelist isn't enough. This is awkward, in my opinion.
> 2. Integrate to another, stable branch. Which is cleaner (and is what we
> do/did), but you're still just choosing to integrate a possible mish-mosh
> of changelists, baselines, etc.
> It's easy to pick and choose in #2 and your build/CM branch always only
> has the code you want in it.
So all you need is the filespec of your build tree for this version,
and the latest submitted changelist on that tree.
All our release build procedures include nuking your client tree and
syncing it freshly to a known changelist number. Some of them do this
part automatically in Python, making a temporary Perforce client to
get a guaranteed-fresh tree. For instance, see the code around line
As for the question of what version marketing want, that can be
handled by proper version branching. We don't build releases from our
master sources, we build them from version branches. For instance,
P4DTI release 2.2.2 was built from
//info.ravenbrook.com/project/p4dti/version/2.2/... at 142783
We don't use labels.
More information about the perforce-user