[p4] Changelist number in versions

[Shawn Hladky]

You can create a pending changelist, and use that number.
Here's roughly what we do:
Create pending changelist n.  n is the "build number"
p4 sync //depot/branch/... at n
Compile code (embed n in binaries if you wish)
Submit binaries (//depot/branch/bin/...  not using pending change n...
change number will be n+x)
Submit bill of materials (//bom/project/<n>  using pending changelist n
which is renumbered to n + y)

The BOM includes all data we need to reproduce a build... literally run
build.bat <n> to reproduce build 'N'.

It is a little confusing that the binaries are submitted with a changelist
higher than the build number.  But once you accept that the build number
does not directly map to any submitted changelists (it's just a
point-in-time), then the process works well.  You still get the benefits of
a unique and time-consistent build number.


On Dec 17, 2007 2:21 PM, <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
>