[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] Issue #1093: make diff follow history

From: Josh Pieper <jjp_at_pobox.com>
Date: 2004-05-12 01:42:50 CEST

Josh Pieper wrote:
> kfogel@collab.net wrote:
> > Ben Collins-Sussman and I spent some time this morning going over the
> > both the old and new syntax, and we're +1 on the new. This proposal
> > solves the peg problem.
> >
> > But, does this mean we'd lose the old syntaxes? The old syntaxes are:
> >
> > 1. diff [-r N[:M]] [--old OLD-TGT] [--new NEW-TGT] [PATH...]
> > 2. diff -r N:M URL
> > 3. diff [-r N[:M]] URL1[@N] URL2[@M]
> >
> > The new ones you're proposing are
> >
> > 1. diff [-r N[:M]] [TARGET[@REV]...]
> > 2. diff --old=OLD-TGT[@OLDREV] --new=NEW-TGT[@NEWREV] [PATH...]
> > 3. diff OLD-URL[@OLDREV] NEW-URL[@NEWREV]
> >
> > I'm just thinking about UI compatability and release scheduling. Can
> > we release a diff syntax change in 1.1? That seems a bit much, unless
> > the change *only* adds new syntaxes, doesn't take away any of the
> > existing ones.
>
> The only incompatible change the new syntax has is removing support
> for the -r option in case 2 and 3. It would be no extra
> implementation work to accept those options with their pre1.1
> behavior. As far as I could tell, they were removed to prevent
> confusion, since only case 1 really is guaranteed to diff the same
> object at two different revisions. Perhaps we could mark them as
> deprecated?

I believe I was mistaken in my first look at the compatibility issue.
If -r options were accepted for all three newly proposed formats for
diff, then there would be no way to distinguish case 3 from case 1.
What to do about it, I am not sure.

-Josh

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 12 01:43:07 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.