On 06.02.2013 00:58, Stefan Sperling wrote:
> Joke aside, I'm not sure if there is a really good way to resolve
> these ambiguities. I don't really like that fact that we've got these
> --old and --new options in the first place. It seems like a crutch for
> a lack of a better syntax that can express all use cases equally well
> without being rather weird and uncommon. But since the syntax is
> present in releases we have to keep supporting it...
I agree about not liking --old and --new. But we went through exactly
the same arguments back in the day when they were invented, and the
argument that won was against confusing users with the fact that:
$ svn diff param1 param2
could have two completely different meanings based on some magic
involved in interpreted the parameters, whereas:
$ svn diff param1
or
$ svn diff param1 param2 param3
can each have only one meaning.
I think the only way out of adding --new and --old, given the premise
that user confusion was absolutely evil (which I agreed with and still
do), would have been to have only two forms of "svn diff" -- the
one-parameter form that produces a historical diff, and the
two-parameter form which would produce a diff between the two targets.
However, that was seen as insufficient, given the (then) goal of CVS
feature parity, and simple usability required that we had a way to
produce historical diffs for N targets (where N >= 1).
Given all the above, I think we should find a way to warn users -- with
a one-line note in the header of the diff output, for example? -- about
the cases where the two-parameter diff could be ambiguous (which, I
believe, is when both parametrs are WC paths or URLs); and further, when
any of the paths are unversioned.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
