[p4] Changelist number in versions

[Tetrick, Cary]

We do something similar. We do keep a copy of the version.h file in
Perforce so that programmers don't have to generate the file, but our
automated build system gets the changelist number it needs, and
generates an up to date version for published builds.
We don't update the stored version unless there are some other changes
to the file, which are very rare.

-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of Ivey, William
Sent: Monday, December 17, 2007 3:39 PM
To: perforce-user at perforce.com
Subject: Re: [p4] Changelist number in versions

In our system version.h is a generated file and, thus, need
not be tracked in Perforce. (The scripts and makefiles or ant
build files that generate it are.)

-Wm

-----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 3: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

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