Charles Acknin wrote:
> 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.
Consider the case where someone tries to apply the patch to a tree
that's different from the original except for the coincidence that 'foo'
exists in both. And imagine that foo is a directory being deleted by the
patch. Without any contextual info in the tree modification description,
such a patch will happily get applied.
So ... is there a good reason /not/ to include contextual info in tree
diffs? And not to intersperse tree changes with file diffs?
> 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.
I missed the part about checksums, yes.
> 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).
Indeed, but when thinking about a patch format, it's more important to
consider how Subversion deals with /conflicts/ in binary files.
If your patch contains the hash of the source file, and a binary diff
against that source; and it's applied against a changed file; we can
tell the user that the patch can't be applied, and that's it. There is
no way for the user to resolve the conflict, and if, for example, the
resulting tree doesn't build ... well, tough luck.
In the parallel case, Subversion will flag a conflict, but allow the
user to decide how to resolve it -- both the current working copy
version and the changed version will be available. IMHO the patch should
offer the same convenience.
If you're worried about the size of the patch: If the binary files
matter enough to be included in the patch, then the size is likely to be
irrelevant.
-- 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 21:01:43 2007