[p4] Changelist number in versions

[todd.benham@kodak.com]

Thank you for some 20+ responses. What a helpful group!

My conclusion is that what I *really* want to do is impossible unless we
were willing prevent check-in's on the server during the "critical"
section of the process. Apparently, I confused some of you -- in step 1),
I meant "p4 integrate" into a new directory ... so there won't be a change
list number using "p4 changes" until step 5).

So my revised plan is to use $Change$ keyword expansion (and/or the
P4Python) for getting the number into the version.h file. Then p4 add it
in the same changelist as the branch and submit. Then build from change
list number (in case it changed), then submit a separate changelist with
"built" items. I have some details to iron out but the idea is in place.

Several of you suggested that I need not bother adding version.h to the
release since it is generated and I understand that idea. But we have
certain habits that make checking in the file kind of useful.

Todd 


-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of Todd D. Benham
Sent: Monday, December 17, 2007 4:22 PM
To: perforce-user at perforce.com
Subject: [p4] Changelist number in versions


I have poked through various help and online notes such as
(http://maillist.perforce.com/pipermail/perforce-user/2005-March/014822.ht
ml) but can't fully find the answer to this "catch-22" situation.

I see that Perforce displays the changelist number in the version of their
products such as Perforce Visual Client/NTX86/2007.2/128166.

Great idea but I cannot really see how this can be done, correctly, in
Perforce. It seems there is a always a risk of getting the wrong
changelist number in the build. Here is my dilemma by example: 
1)      Branch from main\proj1 to release\v1.01\proj1
2)      Grep the changelist number out of p4 changes or whatever (et. al.,
a whole different discussion) 
3)      Generate version.h with the change num and version. P4 add to
release\v1.01\proj1\inc\version.h.
4)      Perhaps, build, test, add built binaries, rel notes, whatever.
5)      Submit changelist

It is nice to have only one changelist for a release but now in #5, the
changelist number might change because elsewhere on the server someone
else submitted something. Yet, it is already embedded in the build.

What do people really do? Some choices:
a)      Don't bother trying to track the changelist in version.h. Just use
release notes or something.
b)      Don't allow other submits while building a release (not realistic
on a popular server).
c)      Use multiple changelists in a single release.
d)      Use Labels instead of changelist number.
e)      Submit everything in a really short time and THEN build. Keep the
"race" to a short time frame where it is unlikely that anyone submits in
between. But then we need a second changelist in the release branch for
"built" item which are not available until the build happens. Then, this
is confusing of which changelist is THE change list to re-build from if
necessary.
f)   Other

I assume many of you understand and have dealt with this race condition.
Am I missing something? 


In case it is relevant, we use: Windows, Python, P4Python, p4v, p4, batch
files




Thank for any help, 

Todd Benham 

_______________________________________________
perforce-user mailing list  -  perforce-user at perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user