[p4] Re: determining the status of a clientspec

Jeff A. Bowles jab at piccoloeng.com
Tue Oct 9 16:14:37 PDT 2001

Lots of people have written good posts on this thread.

Here's a followup:

It is handy to know the most recent changelist number pulled onto a client 
1. A few people have pointed out that this could be misleading - okay, you 
now know that changelist 8842 is the most recent changelist pulled down. 
That doesn't meant that "p4 sync //depot/... at 8842" will retrieve an 
identical set of files, because:
	a. The user might've pulled down changelist 8842 explicitly,
	    and doesn't have all the changes up-to-and-including 8842.
	b. Of course, the client spec itself might only include files from
	    //depot/main/src/lib/libgui/..., so there's the possibility that
	    you only have a cross-section of the /depot/... tree pulled down.
	    So knowing that it's changelist 8842 might not be sufficient to
	    recreate the body of source files current in your workspace.
2. What do you plan to do with this changelist number?  It's really not 
that helpful by itself, really, it's not.

So, if you're trying to tell Sue - in the next cube over - that your work 
is included in change 8842, that's great. Have at it. (She can run "p4 sync 
@8842" and will update her workspace to retrieve all files 
up-to-and-including 8842, and if she's got a similar client spec Views: 
section for the area she's pulling down, she'll retrieve the same stuff 
you've retrieved.)

If you're trying to figure out, after the fact, what's in your workspace, 
then "p4 changes -m1 -s submitted  filelist" is handy.

But don't use that to track a build that you're going to release. Don't 
even THINK that it's an option.

If that's the intent, either make a label or record the change number 
BEFORE doing the sync. (A lot of build scripts run "p4 changes -m1 -s 
submitted  //depot/main/..." to get the change number, and then "p4 sync 
//depot/main/... at 98912" to retrieve the files.  They then put  "#define 
VERSION 'main/98912'" into a header file to reflect the way to recreate the 
source tree for patches.)

So the question originally posed invites a lot of questions in response. If 
it's for your build scripts or your release mechanism, you might need to 
bark up a different tree to find the squirrel you're hunting for.

	-Jeff Bowles
	Perforce Certified Trainer, Consulting Partner

More information about the perforce-user mailing list