[Gnu-arch-users] Re: Binary Diff System in Arch

[Martin Pool]

On Wed, 04 Feb 2004 08:59:18 -0800, Tom Lord wrote:

>   The first two equations -- exact patching -- should be fairly easy.
>   A good suggestion was made at one point that the output of
> 
>       % xdiff a.jpg b.jpg
> 
>   should include md5 checksums for both a.jpg and b.jpg, along with
>   the xdelta output.  (I'm assuming that xdelta doesn't already
>   include those checksums in its output).

No, it does include checksums.  xdelta will not let you apply a delta
to the wrong basis file.  From the manual

       By default, Xdelta always verifies the MD5 checksum of the
       files it reconstructs.  This prevents you from supplying an
       incorrect input during patch, which would result in corrupt
       output.  Because of this feature, you can feel confident that
       patch has produced valid results.

This would mean that 'xdelta patch' requires an exact match on the
input which is I suppose the desired result.

>   What if the checksums don't match?  Unlike textual patching, 
>   binary patching can't reasonably "fudge it".   So if the checksums
>   don't match, then xpatch and xreverse_patch should leave the
>   file being patched unmodified -- and store the entire xdiff output
>   as a .rej file.

>   xdiff3 is easy, given xdiff.  If ANCESTOR and MERGED-TO are exactly
>   the same, then the merged file output should just be a copy of
>   MERGED-FROM.   Otherwise, the output should be a copy of MERGED-TO 
>   and "xdiff ANCESTOR MERGED-FROM" stored as a .rej file.  (Note -- 
>   tla will need a slight modification to how it handles the .rej
>   file in this case but nothing major.)

I think it might be more useful to produce three files: MINE, OTHER,
and ANCESTOR (as Subversion does).  The .rej for an xdelta is not very
useful to the user, because they cannot fix or apply it by hand the
way they can with a textual delta.  Also it is not possible for only
some chunks of an xdelta to fail.  The only useful thing for arch to
do with the delta is to apply it.

xdelta should be entirely an internal optimization, as a more
efficient way to store changes in binaries.  I can't think of any case
where it would be useful to the user to see the xdelta.

-- 
Martin