[p4] automatically building in the latest changelist number for abuild
streak at narus.com
Wed Mar 23 19:03:43 PST 2005
Matthew Janulewicz wrote:
> 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.
Using the changelist number is meaningless in terms of determining the
level the code is at. But that's not the useful part of using
changelists in a version number. It becomes useful when you need to be
able to recreate the existing build or debug it in any way.
Depending on how your code is structured, the latest changelist can tell
you exactly how to reproduce what's been created. A label can tell you
the same information, but a label doesn't necessarily tell you any more
about the level the code is at either. It all depends on how you use
In our case, our output is tagged with a label that determines what
level the code is at (alpha, beta, etc.).
> 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.
If this happens early in the product lifecycle, this shouldn't be an
issue since the "level the code is at" should also be somewhat related
to the stage of the product lifecycle.
If marketing chooses to change the product late in the product
lifecycle, you'll have bigger quality issues than what label the code is at.
> If your marketing department never changes it's mind, and if your
> engineers only check in perfect code, in the order it is needed, then
> using merely a changelist number to identify code might be a good idea.
> But in a non-perfect world (which all worlds eventually become) you
> won't be able to stick to that policy/philosophy.
If you use the changelist merely as a way of reproducing a given build
and not confuse it with the level the code may be at, it sounds like
there's no problem.
> Personally, I'd rather have a plan to accomodate it before it happens so I don't end up
> with two different software identification methods.
Won't you need two methods anyway?
There's the marketing department and how they choose to identify the
software (through version numbers, etc.) And then there's the
engineering department that may have its own way of identifying builds.
In this case, the changelist/label/branch information becomes
> As far as I know (willing to be schooled in this if
> I'm off the mark) a change list alone is not a sure-fire way to figure
> out what was in a build at any time.
That depends on how you work.
At the moment, we resync an entire tree at a given changelist number.
So a changelist IS a sure-fire way of figuring out what was in a build
in our case.
The useful function I see in a label is the label name can determine the
level of code. But the label name isn't necessarily useful in
recreating a given build. It's the label contents that do that.
More information about the perforce-user