Determining the last changelist synced to in Perforce

Question

A question that occasionally arises is what is the best way to determine the changelist that you last synced to in Perforce. This is often needed for things like injecting the changelist number into the revision info by the automatic build system.

Answer 1

Just to answer this myself in keeping with Jeff's suggestion of using Stackoverflow as a place to keep technical snippets....

From the command line use:

p4 changes -m1 @<clientname>

And just replace with the name of your client spec. This will produce output of the form:

Change 12345 on 2008/08/21 by joebloggs@mainline-client '....top line of description...'

Which is easily parsed to extract the changelist number.

Answer 2

Erickson - nice suggestion, but I think it covers a slightly different set of circumstances than the answer I provided. Certainly counter will work if you are likely to only have the head revision, and the server is not busy enough so that someone, perhaps working on another project, would not do a submit between syncing and calling p4 counter.

So I think your suggestion is probably best when the build system is doing a distinct pull then build. My answer covers cases where the sync may be separated in time from the build.

Both are valid depending on circumstances I think.

Answer 3

I recommend the opposite for automatic build systems: you should first get the latest changelist from the server using:

p4 changes -s submitted -m1

then sync to that change and record it in the revision info. The reason is as follows. Although Perforce recommends the following to determine the changelist to which the workspace is synced:

p4 changes -m1 @clientname

they note a few gotchas:

• This only works if you have not submitted anything from the workspace in question.
• It is also possible that a client workspace is not synced to any specific changelist.

and there's an additional gotcha they don't mention:

• If the highest changelist to which the sync occured strictly deleted files from the workspace, the next-highest changelist will be reported (unless it, too, strictly deleted files).

If you must sync first and record later, Perforce recommends running the following command to determine if you've been bit by the above gotchas; it should indicate nothing was synced or removed:

p4 sync -n @changelist_number

Answer 4

You may try finding the maximum change number in the output of the "p4 files" command. The working directory should not contain post-sync commits, though. This is just a tad better than

p4 changes -m1 "./...#have"

as the latter seems to run on the server and may fail on big source trees due to "MaxResults" limits.

$ p4 changes -m1 "./...#have"
Request too large (over 850000); see 'p4 help maxresults'.

$ p4 -G files "./...#have" | python c:/cygwin/usr/local/bin/p4lastchange.py
Files: 266948
2427657

where p4lastchange.py is based on the code from the Using P4G.py From the Command Line presentation by J.T.Goldstone, Kodak Information Network/Ofoto, April 15, 2005.

#! /usr/bin/env python
import sys, os, marshal

if os.name == "nt":
    # Disable newline translation in Windows.  Other operating systems do not
    # translate file contents.
    import msvcrt
    msvcrt.setmode( sys.stdin.fileno(), os.O_BINARY )

lastcl = 0
num = 0
try:
    while 1:
        dict = marshal.load(sys.stdin)
        num = num + 1
        for key in dict.keys():
            # print "%s: %s" % (key,dict[key])
            if key == "change":
                cl = int(dict[key])
                if cl > lastcl:
                    lastcl = cl
except EOFError:
    pass
print "Files: %s" % num
print lastcl

Answer 5

The best I've found so far is to do your sync to whatever changelist you want to build and then use changes -m1 //...#have to get the current local changelist (revision).

p4 sync @CHANGELIST_NUM p4 changes -m1 //...#have | awk '{print $2}'

Gives you the changelist number that you can the use wherever you want. I am currently looking for a simpler way than p4 changes -m1 //...#have.

Answer 6

I get this:

p4 changes -m 1 @tim-wurblefish Request too large (over 250000); see 'p4 help maxresults'.

Seems I'll be using g4 files ...