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.
