[p4] Changelist number in versions

[Stephen Vance]

The changelist number should only come from the branch (i.e. 'p4 changes 
-m 1 -s submitted release\v1.01\proj1\...'). No one else should be 
submitting to the release branch during a release period. You're 
supposed to be stabilizing the code there. Or you can just build off of 
a known changelist version.

You really don't even need to check in your version.h. If it's always 
generated automatically, then it just reflects a fact about your depot 
and doesn't need to be versioned.

Steve

todd.benham at kodak.com wrote:
> 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
>
>   

-- 
Stephen Vance
www.vance.com