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

Matthew Janulewicz Matthew.Janulewicz at cardinal.com
Wed Mar 23 16:51:45 PST 2005

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.

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. 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.

If you read between the lines here, you might detect that I'm an advocate  
of labeling builds. It's been said that the negative is that labels can be  
changed/edited, and changelists are etched in e-stone. But my take is that  
I'm a CM professional, I know what I'm doing, I lock my labels, I document  
what I do, I believe in me, I'm paid to do this stuff, yaddah yaddah  
yaddah. I just see a changelist number as a point in time, which may or  
may not reflect the code that's in any build at that time. 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. Technically, neither is a label, but I'd rather have a label as a  
base/starting point that just a changelist reference.


On Wed, 23 Mar 2005 16:58:53 -0500, Leo Zelevinsky  
<leo.zelevinsky at gmail.com> wrote:

> It feels certain that others have run into my design problem before
> and I don't want to reinvent the wheel.
> We have recently moved from SourceSafe to Perforce. Recently, we have
> decided to adopt the perforce strategy for numbering versions - so
> that in the version label is built in the latest changelist that was
> used in making the build.
> I am wondering what would be the best way to make this as foolproof as
> possible. For instance, I'd like our Help/About box to display the
> latest changelist checked in when this code was last synced. What's
> the best way to get at that information?
> I am thinking that it should be something like a script I run as part
> of the sync which in addition to the sync would create a .h file with
> the latest changelist information (I guess gotten via p4 changes -m 1
> -s submitted).
> Do others do this sort of stuff? Any tips?
> Thanks!
> _______________________________________________
> Come to the 2005 Perforce User Conference, April 14 & 15 in Las Vegas.
> Learn more: http://www.perforce.com/conf
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user

More information about the perforce-user mailing list