[p4] automatically building in the latest changelist number for abuild
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?
> 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
More information about the perforce-user