[p4] Re: determining the status of a clientspec

Dennis Wheeler dennis.wheeler at pictureiq.com
Tue Oct 9 17:24:38 PDT 2001

Rick Macdonald wrote:
> I use a slightly different command in my builds:
> p4 changes -m1 -s submitted //$P4CLIENT/...
> I believe this gives me the highest submitted changelist number for any
> file in the clientspec. But the key is I then run
> p4 sync //$P4CLIENT/...@$CHANGE
> In this way when I stash my build number it truly represents what I need
> to sync to later duplicate the set of files. But be clear: my intention is
> to build the latest contents of the depot, not to determine or record the
> contents of the workspace before my build runs.

Yes, that was my workaround, because that the same way I use it for
(it's tucked away in a script somewhere).

> > 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)
> >


  p4 changes -m1 -s submitted //$P4CLIENT/...
       change 12346 (this is correct revision -- assign to $CHANGE)
  p4 sync //$P4CLIENT/...@$CHANGE
       (now I know what I have)  

tells me what I'm going to get before I get it.

 But if I forget, or if there's been other submissions and I'm not ready
to sync to the latest, then there's no way to accurately determine what
I currently have (after I've got it).

It's very, very minor.
Because it's only true if the last sync'ed (what's the past tense of
sync?) change only contains deletions. But it's been bothering me for a
long time.

  p4 changes -m1 //my_client/... at my_client
  p4 changes -m1 //depot/... at my_client
  p4 changes -m1 ./localpath/... at my_client

All these now seem to indicate incorrectly that I do not "have" change
12346. Which technically is true, I don't "have" those files (because
they've been deleted), but it's very misleading.

-- dennis

More information about the perforce-user mailing list