Having thought more deeply, I don't think you can usefully write a single
description of the behaviour. I think you need to organise this definition
according to purpose:
* For summarising the changes for a human, and usable by conventional "patch"
to a reasonable extent.
* For generating a patch that a conventional "patch" program can apply to the
greatest extent possible, with the remaining information as annotations for a
human.
* For generating a patch that a future Subversion "patch" program can apply to
recreate the changes exactly.
* For compatibility with the current "svn diff" (excluding any behaviours that
we agree are definitely bugs).
File renamed from dir/F1 to dir/F2:
(human) "R dir/F1 -> dir/F2"
(oldpatch) diff deleting F1 + diff adding F2
(svnpatch) "R dir/F1 dir/F2"
(compat) "D dir/F1" + diff adding F2
Property P deleted from file F:
(human) Same as (compat).
(oldpatch) Same as (compat).
(svnpatch) [...]
(compat) "Property change on F:" + [...]
[...]
Malcolm Rowe wrote:
> On Mon, Oct 10, 2005 at 01:55:19PM +0100, Julian Foad wrote:
>
>>>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?
But you say existing "patch" will convert one tree into another. Oh, you mean
by brute force and heuristics: if you supply an all-lines-deleted patch, it can
delete the file, and if all files are deleted, it can delete the directory,
etc. I don't necessarily think that's what we should output by default.
> 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.
Then renaming a root directory would result in a huge delete-and-add patch.
What is this output intended to be used for? That would be bad for showing the
user; it would be bad for submitting a patch to a project for review; it would
only be good for generating a patch that can be automatically applied by an
exisiting Patch program. But no exisiting Patch program can apply the whole of
an arbitrary Subversion diff automatically, so is that really useful? Only in
limited circumstances, I think.
Is that really what our current "svn diff" output is intended to be? That's
why I think we need to specify useful behaviours, and then specify the current
implementation in terms of them and decide whether and how much to change it.
>>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.
Right, this was a case of me not distinguishing between different intentions.
>>>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.
Yes. I was trying to get at some sort of wording to make clear the
relationship between the output of "diff a b" and "diff b a", so as to make
clear that the current bugs resulting in asymmetrical output for those cases
really are bugs. But it's obvious; no such description is necessary.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 11 17:55:20 2005