[p4] Re: determining the status of a clientspec

Jeremy Russell jrussel at reshape.com
Wed Oct 10 09:46:57 PDT 2001


The way I went about solving this delima was to determine which changelists I 
did NOT have.  Because of the ability to update partial branches, I find this 
to be much more useful than knowing which was the last changelist updated.  
As has been pointed out by so many people, just because you have a higher 
numbered chnagelist synced, does not say with certainty that you have the 
lower numbered changelists synced, nor that you have and changelist synced in 
it's entirety.

I do something like the follwing in one of my scripts:
Do p4 sync -n and store the list of files which have would be synced.

Parse that file list to get just the depot path of the files without revision 
numbers and do a 'p4 fstat' which tells me the revision of the file I have, 
the head revision number, and the changelist which created the head revision.

Now comes the tricky part.  If I do a 'p4 fstat' and specify the revision, I 
can get the changelist number which created that revision. So, I recurse the 
revision list until I reach the revision of the file that I currently have.  
Let me give an example to clarify:
	fstat will tell me I have rev 5.
	head is rev 8
	I want to know which changelists created 6 and 7 as well as 8.
	so I do: 
	'p4 fstate file#7'
	'p4 fstat file#6'
	'p4 fstat file' or 'p4 fstat fil#8'
I save all of this information in sometype of container.

I then can do a 'p4 describe -s <change>' and get a list of files for a given 
change.  Because I have a list of the files that I would be bringing over 
during a sync, all the changelists that created them, and now I have a list 
of the files in each changelist, I can get a few bits of data:
	- if the client synced only a partial changelist - you even have enough info 
	determine which file from the change list have not been synced.
	- if I will need to do any resolve if I sync (well, you can get this by 
	just 'p4 sync -n', but I find this to be much more useful
	- which was the last chnagelist that I synced in its entirety.

At this point it becomes a task of manipulatiing the infomration collected to 
get the data desired.  But I think using the 'p4 fstat' in the way I have 
described is very useful.

In more specific terms I created an fstat object in Perl that collected all 
of this infomration, including the changelist history for each revision.  It 
was not that hard and it is very specific to my environemtn here, but the 
purpose of fstat is for the automation of these types of tasks.

Just my 2 cents on this issue...and a completely different way to get your 
information...

-Jeremy

On Tuesday 09 October 2001 03:17 pm, Dennis Wheeler wrote:
> perforce-user-request at perforce.com wrote:
> > "p4 changes  //depot/main/src/..."  tells us about all changelists
> > that affected files under //depot/main/src/, and
> > "p4 changes -m1 will restrict the output so that it's only the
> > most recent one ('-m1') changelist.
> >
> > So, "p4 changes -m1  //depot/main/src/... at garfield" will tell
> > us about the most recent changelist GIVEN to client workspace
> > "garfield".
>
> Except, if the last changelist only contain deletions, then it will
> report that your most recent changelist # is the previous  changelist
> number
>
> So if, for example, you were to use that number to sync another client,
> or re-sync your current client, you would end up with the wrong set of
> revisions.
>
> example:
>   change 12345
>     some edits....
>   change 12346
>     delete this file
>
>   p4 sync ...
>     (file deleted in change #12346 has been removed from client)
>   p4 changes -m1 @my_client
>     change 12345 (this is wrong)
>
> I once knew a work around for getting the correct number, but I've
> forgotten it.
>
> -- dennis
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user



On Tuesday 09 October 2001 03:17 pm, Dennis Wheeler wrote:
> perforce-user-request at perforce.com wrote:
> > "p4 changes  //depot/main/src/..."  tells us about all changelists
> > that affected files under //depot/main/src/, and
> > "p4 changes -m1 will restrict the output so that it's only the
> > most recent one ('-m1') changelist.
> >
> > So, "p4 changes -m1  //depot/main/src/... at garfield" will tell
> > us about the most recent changelist GIVEN to client workspace
> > "garfield".
>
> Except, if the last changelist only contain deletions, then it will
> report that your most recent changelist # is the previous  changelist
> number
>
> So if, for example, you were to use that number to sync another client,
> or re-sync your current client, you would end up with the wrong set of
> revisions.
>
> example:
>   change 12345
>     some edits....
>   change 12346
>     delete this file
>
>   p4 sync ...
>     (file deleted in change #12346 has been removed from client)
>   p4 changes -m1 @my_client
>     change 12345 (this is wrong)
>
> I once knew a work around for getting the correct number, but I've
> forgotten it.
>
> -- dennis
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user



More information about the perforce-user mailing list