On Mon, Oct 10, 2005 at 01:55:19PM +0100, Julian Foad wrote:
> Thank you _very_ much for asking. We sorely need this defined and the bugs
> and quirks in "diff" ironed out.
Oh good, I'm glad it's not just me who thinks the broken bits need fixing!
> >1. 'svn diff' accepts two path/revision pairs, each representing a
> >subtree of a repository or working copy at a particular revision (or
> >BASE or WORKING for the wc). The output of 'svn diff' is something that,
> >when fed to GNU patch, will convert the first tree into the second tree.
>
> Patch: not exactly; you need to say something about how only the
> modifications to individual files are obeyed by Patch, and whether this
> should include whole-file deletes that are part of a whole-subtree delete.
>
Well, I'm defining the output of diff, not the behaviour of patch. I
mention that property modifications are ignored by patch further down;
is there anything else that needs to be clarified?
Why would whole-file deletes _not_ be included in the output of a subtree
delete? (We don't in one or two cases, but they're bugs, no?). They're
necessary to remove the files from the target.
> Also I should think we ought to say explicitly that tree-change information
> should be included in the output in an unambiguous form that might be
> usable by a hypothetical tree-aware Patch program, and can certainly be
> used by a human.
"should", perhaps, but it's not at the moment. Not that I disagree with
you (though I don't know whether it's something we should overload onto
the textual diff format - the old tree-delta XML format was the first
thing I thought of using), but I'm trying to describe what the intended
output is at the moment.
> >3. The output of 'svn diff' will be identical (ignoring ordering)
> >regardless of whether the subtrees are in a working copy or repository.
>
> And something about what the same diff in reverse order should look like.
No: there's no such thing in this model. A 'reverse diff' is simply a
diff with the source and target subtrees swapped.
> And, when we put this specification into more detail, something about how
> the files and revisions are labeled. In particular, what revision number
> or "base" or "wc"-type label is appended to a file name in various
> circumstances.
>
Yes, that sounds like an excellent idea. For example, there's a bug at
the moment whereby for deleted files, we print the revision number of
the source tree anchor instead of the file. Things like that are very
hard at the moment to work out whether they're bugs or not.
> Hooray for you, Malcolm!
Heh. What have I started? :-)
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 11 02:07:34 2005