[I have a bad cold; if any of this email sounds rude, apologies: that's
not the intent.]
On Tue, Oct 11, 2005 at 04:54:18PM +0100, Julian Foad wrote:
> Having thought more deeply, I don't think you can usefully write a single
> description of the behaviour.
I don't know; I think I'm pretty close already. I'm only aiming to
document what we currently intend the output to be, not what it could
more usefully be.
> I think you need to organise this definition
> according to purpose:
I think the definition of 'diff' itself can remain static (though it can
say additional things like "If the 'no-diff-deleted' option is used,
the behaviour is as above except that file deletions are reported only
in summary). But you're right that we need some kind of mapping from
purpose to options.
> >>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.
>
But it _is_ what we output, except for repos-repos diffs (that's issue
2333).
> >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.
>
Agreed, on all points, except: it's called 'diff'. We already do things
to make sure the output of diff is a valid input to patch (for example:
we output no-content diffs for new empty files; one reason noted is so
that patch will create the file).
If we had called it 'svn whatchanged' or something _other_ than diff,
or if its output _wasn't_ typically parsable by patch, I'd have a far
better time accepting that we could arbitrarily change the default output
to something else (for example, putting in a 'renamed' comment rather
than a deleted+added diff, when directories are renamed).
Don't get me wrong: I think it would be great if svn had better tools
to report differences between trees, because, as you quite rightly point
out, a basic 'diff' isn't ideal for reviewing changes in all cases.
You already mentioned the file or directory-renamed problem. Only
yesterday, I was reordering functions in a file, and I thought that it
would be significantly more useful had diff been able to show me that
the text in the file had just been moved rather than added and deleted.
But not by default?
Also, technically, while we continue to represent renames as paired
'delete' and 'add-with-history', it's not possible to reassemble the
operations into a single 'rename' operation in all cases (for example:
delete of 'A', add-with-history B from A, add-with-history C from A. Is
that a rename of A->B and an add-with-history of C, or A->C and add B,
or A->(B and C)). That's not to say we couldn't try, of course.
> Is that really what our current "svn diff" output is intended to be?
That being my original question, of course :-)
Perhaps Karl et al could provide some guidance?
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?
> 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.
Ok. I don't have enough time to drive that, which is why I'd prefer
to document what appears to be the current intended behaviour, and
possibly the deviations from that (though most are in the issue list,
so there'd be some duplication there). Perhaps we could produce something
jointly?
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 13 12:05:44 2005