[p4] Changelist number in versions

[Raja Aluri]

Hi Todd,

I always generate the version.h file, from a template during the build with
the changelist and a lot of other metadata related to branches, components,
environment etc., 

Before the build starts, I always sync the source to a known point (highest
changelist at the beginning of the sync, for that branch), so there is no way
of changes getting into your client, while you were syncing the tree.

Raja


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