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

jab jab at pobox.com
Wed Mar 23 17:23:37 PST 2005


The short answer to the original question:
	for overnight build-to-head-of-branch needs, you can run this at the 
top of your bulid script:
	"p4 changes -s submitted  -m1  //depot/main/..."		(for 'main', as an 
example)
	Then paw through the output, and the second field is the change number 
of the most
	recently submitted change in that line. Record 'main' and that number, 
into your version string.

Matthew brings up many good points about doing release builds this way. 
In effect, he says "you are
welcome to track releases by change number / branch combinations, but 
don't mislead yourself. Make
sure that the branch/codeline you're building has clean-enough checkins 
or is constructed so that it's
a destination branch that holds only release-quality stuff, then use 
this strategy."

	-Jeff Bowles

On Mar 23, 2005, at 4:51 PM, 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. 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.
>
>
> -Matt
>
>
> 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
>
>
> _______________________________________________
> 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