[p4] Changelist number in versions

[Stephen Vance]

You could 'p4 lock' the branch to prevent anyone (else) from checking 
in, edit your version.h in a numbered pending changelist, validate the 
build, check in version.h, then unlock the branch. You could even create 
the changelist up front for your integration, make the version.h change 
a dirty edit, and check it all in at once.

It's not really the Perforce way, but if I read your intent correctly, 
it should fit the bill exactly.

Steve

todd.benham at kodak.com wrote:
> 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
>
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>
>   

-- 
Stephen Vance
www.vance.com