On Fri, 2005-10-14 at 16:36 +0100, Malcolm Rowe wrote:
> 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?
Yes.
> 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?]
I'd say so.
> 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"?
"svn diff" should, by default, present tree changes in the most
reviewable way possible, because that's how it generally works now and I
think people rely on that. That's not the same as saying 'the
definition of svn diff is the output svn diff produces'.
> 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?
It's true that "present tree changes in the most reviewable way
possible" is a somewhat more squishy definition than "present tree
changes in a way that they will be reflected by patch". But I don't
think it's the same as deciding everything on an ad hoc basis.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 14 21:08:18 2005