[p4] Revision confusion

Rick Macdonald rickmacd at shaw.ca
Thu Aug 30 10:21:50 PDT 2007


Perhaps a clue supporting all of this is that p4win used to (still 
does?) have a context-sensitive (right-mouse) option in the Pending 
Changelist pane that said "Schedule file for resolve". It simply ran a 
sync on the file. It makes sense that the "have" revision changes as 
that's maybe (part of) how they keep track of the need to resolve before 
submitting.

Like Dave mentions, the familiar scenario is editing an older file and 
then syncing and resolving to the head. Is there any meaningful use of 
resolving to an older file when editing a newer revision? One might be 
tempted to think this is a way to undo the later revision (by resolving 
with -at?), but without testing I'm not sure if it would do it. Tech 
note 14 does it in a different, more logical order: sync the old one 
specifically, then edit, then sync to head, then resolve -ay.

Rick

Dave Lewis wrote:
> This seems consistent with the way it works when editing an older
> revision, then syncing and resolving to the head revision...  the one
> part that really surprised me was the output of p4 have.  it makes
> sense, but I guess I had never thought about the have list reflecting
> the sync so specifically.  I had tended to think it reflected what was
> on the client.
>
> The other surprise was that the revert reverted you back to the
> revision you had synced to, rather than the revision you had opened
> for edit.  That makes sense too, but I had not thought about this
> case.  it is an unusual scenario, it seems to me.
>
> I guess fstat will tell you the details relevant to files open for edit.
>
> Thanks for doing that experiment!
>
> dave
>
> On 8/30/07, Ivey, William <william_ivey at bmc.com> wrote:
>   
>> I was watching the modtime thread and tried an experiment,
>>
>> the results were interesting:
>>
>>
>>
>>     
>>> p4 have BuildIt.dat
>>>       
>> //depot/main/BuildIt.dat#2 - /opt/simcity/auto/daily/main/BuildIt.dat
>>
>>     
>>> p4 edit BuildIt.dat
>>>       
>> //depot/main/BuildIt.dat#2 - opened for edit
>>
>>     
>>> p4 sync BuildIt.dat#1
>>>       
>> //depot/main/BuildIt.dat#2 - is opened at a later revision - not changed
>>
>>     
>>> p4 have BuildIt.dat
>>>       
>> //depot/main/BuildIt.dat#1 - /opt/simcity/auto/daily/main/BuildIt.dat
>>
>>     
>>> p4 revert BuildIt.dat
>>>       
>> //depot/main/BuildIt.dat#1 - was edit, reverted
>>
>>     
>>> p4 edit BuildIt.dat
>>>       
>> //depot/main/BuildIt.dat#1 - opened for edit
>>
>> ... //depot/main/BuildIt.dat - must sync/resolve #2 before submitting
>>
>>     
>>> p4 diff BuildIt.dat
>>>       
>> ==== //depot/main/BuildIt.dat#1 -
>> /opt/simcity/auto/daily/main/BuildIt.dat ====
>>
>>     
>>> p4 revert BuildIt.dat
>>>       
>> //depot/main/BuildIt.dat#1 - was edit, reverted
>>
>>
>>
>> Obviously sync doesn't update the file contents, but it does change
>>
>> the revision. -Wm
>>
>>
>>
>> _______________________________________________
>> perforce-user mailing list  -  perforce-user at perforce.com
>> http://maillist.perforce.com/mailman/listinfo/perforce-user
>>
>>     
> _______________________________________________
> 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