On Thu, Oct 13, 2005 at 01:50:28PM -0400, Greg Hudson wrote:
> > Is svn diff primarily intended to be something that produces classical
> > GNU diff unified diffs that can be fed to patch, or is it intended
> > to be a tool that works similarly to GNU diff, but that has differing
> > [default] behaviour in cases where we think those changes would help
> > the user understand the changes better?
>
> I'd say the latter, by default. In the particular common case where you
> have modified files but not reorganized the tree, "svn diff" output can
> be fed to patch, and that's a good thing, but outside of that case I
> don't think we can really achieve that goal in a meaningful way.
Okay - just so that I understand this: in the case where you have only
modified existing files, the output of 'svn diff' should be always be
equivalent to the naïve output that GNU diff would produce, given the two
trees. In all other cases, we will need to choose (or have already chosen)
between that, and producing 'more useful' output. Is that approximately
correct?
So, as a concrete example, does that mean that, if we were to decide
that file or directory renames would be better reported as no-content
'renames' in diff output rather than full-content 'delete/add' pairs,
we would be happy to make that change by default? [I'm not suggesting
that this _is_ a change we'd want to make, but if we _did_, could we?]
> At any rate, we've applied the latter philosophy up until now, and
> people have come to rely on it, so I don't think we can reasonably
> change the default behavior to reflect the former philosophy.
If people are relying on the current behaviour, then it sounds the
answer to my question above is "no". Is the definition of 'svn diff'
therefore effectively "whatever we have now"?
I suppose I'm trying to work out how we decide what is a bug in diff (and
can therefore be changed without violating our compatibility guarantees),
and what is a change to the naïve model that we've made deliberately.
For example, IIRC, issue #2333 basically boils down to the fact that
repos-repos diffs don't report subtree deletions. The other modes
(repos->wc, wc->wc) _do_ report such deletions, but since we don't have
a definition of what 'svn diff' should report, how do we decide which,
if either, should change?
Do we really have to do all this on an ad hoc basis?
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 14 17:37:05 2005