Re: Resolution of 'svn diff' change?

cmpilato@collab.net writes:

> My next instructions were to sell the community on the two-subcommand
> proposition. :-) (Gee, thanks, Ben)

Here's how I see it. We have the following use-cases to cover:

  1. show local mods in a working copy
  2. compare a wc path with a different version of itself
  3. compare two specific versions of a wc path
  4. compare any two arbitrary repos paths/revs

Up till now, we've designed 'svn diff' to have many different syntaxes
and options to cover these cases:

  1. svn diff .
     svn diff file1 file2 file3 [...]

  2. svn diff -r178 foo.c

  3. svn diff -r122:178 foo.c
     
  4. svn diff URL1@150 URL2@200

If you ask me, this current 'svn diff' is already really complicated.

And now, with issue #1142, the dam has broken open. We need to add
this use-case:

  5. compare a wc path to an arbitrary repos path

This new requirement pretty much contradicts the iterative syntax of
use-case #1.

So as cmpilato says, we can either find a new way to get 'svn diff' to
cover use-case 5... perhaps by a new option. But then I think we end
up tottering on making 'svn diff' completely incomprehensible and
unusable.

Yes, new subcommands are generally bad things. We, as a group of
developers, have always shied away from it. But now we're faced with
choosing between two evils: a new subcommand, or a single subcommand
that is impossibly, unusably overloaded.

The proposal from cmpilato, which I like, is to make 'svn diff' cover
only use-case 1. That use-case is what users need 80% of the time.
A new 'svn compare' subcommand would cover cases 2-5, and be somewhat
complex, but no worse than the status quo.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 19 19:06:50 2003