[p4] automatically building in the latest changelist number for abuild

Jason Williams 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 
the label.

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.

Why not?
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 
engineering's mechanism.

> 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 mailing list