Karl Fogel wrote:
> Branko Čibej <brane@xbc.nu> writes:
>
>> Q: How do you correctly apply an svndiff if you don't have the source
>> revision where it came from?
>> A: You can't, because svndiff is based on a block-delta algorithm and
>> does not contain the necessary context.
>>
>> Q: How do you correctly apply an svndiff patch offline even if you do
>> have the source revision?
>> A: See answer to the previous question.
>>
>> Q: How do you apply tree modifications if their description consists of
>> editor commands only?
>> A: You can't, because editor commands don't carry any context -- they're
>> like the '+' and '-' lines in a unidiff, without the not-so-unimportant
>> surrounding bits.
>>
>> (Q: Why do I have to keep pointing this out? A: Mu! :p )
>>
>
> Regarding the application of binary diffs: I thought that Charles knew
> this, and that he was simply punting on applying binary diffs to
> anything other than the exact source file to which they were meant to
> be applied
He distinctly said that the editor command stream used to describe
section b) would not include source revision information. That part I
agree with, since there is no way otherwise to apply patches offline
and/or fuzzily and/or to a tree that's not a working copy. But it
follows that there's be no way to figure out what the exact source file is.
> (as for text files, for which context is useable, those
> diffs come from section 1 of the format, and are represented in
> unidiff format not svndiff).
>
Yup, I was commenting on the second section, not the first.
> I didn't quite follow your point about applying tree modifications via
> editor commands. True, we don't have any way of representing context
> or handling fuzziness in tree rearrangements, but that's a Subversion
> problem in general. The question is, would the proposed format
> preclude the addition of features to handle fuzziness later? If it
> would, what's a better format?
>
I did propose one that would work better -- a unidiff of (canonically
sorted) directory listings. So for example, instead of seeing:
# add dir foo
# rm dir qux
You'd see an equivalent of:
--- before 2007-07-05 09:41:22.816312200 +0200
+++ after 2007-07-05 09:41:50.722740800 +0200
@@ -1,4 +1,4 @@
bar
-qux/
+foo/
xyzzy
zwof/
(with provision to tag renames). This would allow the patcher to detect
conflicts in tree rearrangements without having to look at the
repository history. Note that I'm not proposing this particular syntax;
something like the one proposed, with explicit commands inserted into
the patch as comments, could actually be better -- in fact, such tree
rearrangement notes could be interspersed with the file unidiffs, making
the format more editable and human-readable (since one wouldn't have to
keep jumping between two locations in a patch to understand the whole
picture).
Here's an expanded example with interspersed file and tree changes::
### Tree rearrangements
# @@ -1,4 +1,4 @@
# context bar
# add foo/
Index: gaga
===================================================================
--- gaga 2007-07-05 09:41:22.816312200 +0200
+++ gaga 2007-07-05 09:41:50.722740800 +0200
@@ -1,4 +1,4 @@
bar
-qux/
+foo/
xyzzy
zwof/
# remove qux/
# change xyzzy
# context zwof/
### Binary patches
# change xyzzy fulltext
# <contents of new xyzzy
... etc., you get the picture. By explicitly tagging the type of the
binary patch, there's room for adding support for real contextual
patches for non-text file types; one might imagine, for example, a
pdfdiff format that could describe contextual changes to binary documents.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 5 10:11:27 2007