[p4] Changelist number in versions

[Robert Cowham]

The key thing for me with Alex's method is p4 changes -m1 ... at current_client
(I would use "-s submitted" too)

This gives you what you *are currently synced to* and it doesn't matter if
anyone else checks anything in on that branch around the time you run the
command. One extra check would be by ensuring the following produces no
output: "p4 sync -n ... at NNN". This makes sure the changelist you discovered
above is really what is synced and that there were no errors.

Another alternative to take account of other people perhaps checking things
in:

- find latest submitted changelist on branch
- sync to that changelist (checking for errors, clobber etc)
- use the same number in the build because now you know it is right

I would also point out that Perforce themselves, as shown in their API,
check in a version file with a hand-updated changelist number. Doesn't
really matter what you do as long as it works and is consistently done the
same way every time.

> -----Original Message-----
> From: perforce-user-bounces at perforce.com 
> [mailto:perforce-user-bounces at perforce.com] On Behalf Of 
> alex.pavloff at l-3com.com
> Sent: 17 December 2007 23:06
> To: perforce-user at perforce.com
> Subject: Re: [p4] Changelist number in versions
> 
> 
> We use the changelist in our builds, mainly by modifying our 
> build process to automatically generation your "version.h" on 
> every single build, with something like:
> 
> P4_REV = $(word 2, $(shell p4 changes -m1
> $(PROJECT_ROOT)\...@$(CURRENTCLIENT) ))
> 
> The version.h doesn't get checked in, and you build your 
> final release when there's nothing open for edit (you could 
> add something into the build to check that).
> 
> Works well for us.  You might want to put your output in a 
> different location that the source, that way, all the builds 
> you do won't "pollute" your source tree.
> 
> 	-Alex