[p4] Changelist number in versions

[Oren Shemesh (oshemesh)]

We deal with it like that in our official build process (Our product
shows the change-list number, just like P4):

1. Sync to latest (Or specified) CL
2. Compile with a -D flag specifying what CL we synced to :-)

If you want the product to also contain version/build numbers that get
updated (maybe increment the build no.) during a build, you update your
version.h file and submit it before step 1.

Oren.

Note : When a developer builds a private build, which does not have a
'sync to specified CL' step before it, the -D flag is not specified, and
the software does not show any CL number.

-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of
todd.benham at kodak.com
Sent: Monday, December 17, 2007 11: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