Re: Strange diff behavior on branch

[Greg A. Woods]

[ 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 just one -r and one -D, are you
> trying to specify a single revision (a branch as of a particular date)
> or two revisions (one by tag and one by date)?

Well, let's go through the whole set....

First off if you specify just one '-r' then how it behaves depends on
whether it's a leaf revision ID, or a branch ID.  I think this part
works "right" now.

If you specify just one '-D' then any sticky branch tag should always be
in effect (with the trunk being implied otherwise).  If this is a change
from current semantics then so be it because such behaviour is obviously
wrong and broken.  I don't see that this would be a "radical" change
even if it were a change.

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.

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

-- 
                                                Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <address@hidden>
Planix, Inc. <address@hidden>          Secrets of the Weird <address@hidden>