On 7/5/07, Branko Èibej <brane@xbc.nu> wrote:
> Karl Fogel wrote:
> > 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.
"would not include source revision information" yes, but it does
include checksums when dealing with binary files.
I did update a bit the design note right after posting two days ago,
precisely on that point, see this unidiff (very soon I'll send the
work on a branch, will be much easier to follow-up for everybody):
@@ -31,7 +31,8 @@ Such a format can be seen as a subset of
- Capabilities and Edit Pipelining have nothing to do with as we can't adjust
once the patch is rock-hard written in the file nor negotiate anything
- commands are restricted to the Editor Command Set
- - lacks revision numbers (see VI FUZZING)
+ - lacks revision numbers and checksums except for binary files (see VI
+ FUZZING)
For more about Command Sets, consult libsvn_ra_svn/protocol.
@@ -110,7 +111,9 @@ include a revision number. However, to
lower the patch-application scope we're expecting. For instance, 'svn patch'
would fail at deleting dir@REV when REV is different from the one that comes
with the delete-entry Editor Command. Obviously we need loose here, and the
-solution is to free the svn protocol from revision numbers in our
-implementation. Now dealing with (b) patching is similar in many ways to (a)'s:
-we end up trying by all methods to drive the editor in the dark jungle,
-possibly failing in few cases shooting 'hunk failed' warnings.
+solution is to free the svn protocol from revision numbers and checksums in our
+implementation for every change but binary-changes (for the checksums). (It
+would be insane to associate binary stuff with fuzzing in this world.) Now
+dealing with (b) patching is similar in many ways to (a)'s: we end up trying by
+all methods to drive the editor in the dark jungle, possibly failing in few
+cases shooting 'hunk failed' warnings.
Some words about fuzziness and scalability of this format.
As it lacks revision numbers, tree-changes fuzziness is supported.
Let's consider a patch that carries the move of 'foo' to 'bar'; when
'svn diff --svnpatch' was issued, it was run against foo@X; now it's
perfectly possible to apply the patch in another WC against foo@Y. In
fact as long as 'foo' isn't renamed it works, no matter whether 'foo'
is a contextual-file or a directory.
As for binary files, as Karl said and as mentioned above in the
unidiff, I meant to only apply binary diffs to the same exact file,
i.e. source-file's checksum == target-file's checksum, before, and
after application.
On 7/4/07, Branko Èibej <brane@xbc.nu> wrote:
> 2. For binary files, include the whole file in the patch, and let the
> user sort out the conflicts. That's exactly what the Subversion
> client does, and for very good reason.
I'm not sure I understand what you're saying here. AFAIK, when
dealing with binary file changes, the Subversion client sends/receives
svndiff data, that is, *part* of the file (in most cases).
Cheers,
Charles
Received on Thu Jul 5 20:21:05 2007