On Wed, Feb 06, 2013 at 12:41:05PM +0100, Branko Čibej wrote:
> One other option would be, as was noted elsewhere in this thread, to
> invent a new subcommand for tree comparisons, keeping only the
> historical differences feature in "svn diff".
>
> That would solve the ambiguity, but it would (a) break backward
> compatibility, and (b) invent yet another subcommand, which we don't like.
I don't think we need to change how 'svn diff' works. A new subcommand
could simply provide nicer syntax than 'svn diff' for some use cases.
We can keep 'svn diff' working as it is.
I don't think we should ever change how 'svn diff URL1 URL2' and
'svn diff WC-PATH1 WC-PATH2' work.
But a new subcommand could behave differently in the 'WC-PATH1 WC-PATH2'
case, and compare WC-PATH1 to WC-PATH2. It would essentially be an
alias for 'diff --old --new'. It may need to overlap a lot with 'svn diff',
for options such as --summarize perhaps, and all the little options that
control little aspects of the diff (--ignore-properties,
--show-copies-as-adds, etc). Would it be worth adding? Not sure.
> Yet another option would be to introduce a new option, so instead of using
>
> svn diff --old A --new B
>
> you'd get
>
> svn diff --compare A B
>
> to generate a diff between the two targets, and plain
>
> svn diff A B
>
> to get the historical diff of each target.
I don't think adding a new option to 'svn diff' would help at all.
The point is to unclutter the user interface by providing a more
straightforward way of comparing two paths/URLs with each other.
Another option (especially one that overlaps with functionality provided by
existing --old and --new options) would make the UI even more complicated
than it already is.
Received on 2013-02-06 13:23:56 CET