Re: Strange diff behavior on branch

[Paul Sander]

>--- Forwarded mail from address@hidden

>[ On Sunday, August 3, 2003 at 20:30:04 (-0400), Larry Jones wrote: ]
>> Subject: Re: Strange diff behavior on branch
>>
>> Greg A. Woods writes:
>> > 
>> > It seems to me that it would be most logical and most elegant to simply
>> > use the combination of '-r' and '-D' when a date on a particular branch
>> > is desired:
>> > 
>> >    cvs [r]diff  -r branch-1 -D date-1  -r branch-2 -D date-2
>> 
>> Unfortunately, it's impossibly ambiguous unless you radically change the
>> command line semantics.

>I don't see any ambiguity whatsoever with that specific form where there
>are two of each option supplied.

[...]

>If you specify both an '-r' and a '-D' but just one of each then (I
>think) obviously you mean to diff the current working file with the
>revision on the branch specified by the '-r' (and it would be an error
>for it not to be a branch ID) at the date specified by the '-D'.
>I.e. the '-r' simply replaces any sticky tag that would otherwise be in
>effect.

If you think that this is obvious, then Heisenberg requires that
someone else would think that the obvious response would be to
diff the latest version on the specied branch with the version on
the trunk that is identified by the timestamp.

>Whatever '-r' and '-D' do in combination today cannot be that useful or
>else I suspect you wouldn't have been the only person to point out this
>change.

>Indeed if they currently work to specify two different revisions (and
>the usage message does suggest this is the case) then users can easily
>dis-ambuguate their intent by explicitly specifying a second revision.
>If anyone thinks such a change might be "radical" (I obviously don't :-)
>then the next minor release can warn of the ambiguity; the next major
>release can make the change and warn of how the ambiguity has been
>solved; and the next major release after that can go silent again.
>Anyone who upgrades across multiple major releases had better read the
>release notes carefully!  ;-) 

Spoken as if the end users would do that...

>--- End of forwarded message from address@hidden