Re: fast-import deltas

[Mike Hommey <mh@glandium.org>]

On Tue, Apr 01, 2014 at 10:14:02AM -0700, Junio C Hamano wrote:
> Mike Hommey <mh@glandium.org> writes:
> 
> > On Tue, Apr 01, 2014 at 09:15:12AM -0400, Jeff King wrote:
> >> > It seems to me fast-import keeps a kind of human readable format for its
> >> > protocol, i wonder if xdelta format would fit the bill. That being said,
> >> > I also wonder if i shouldn't just try to write a pack on my own...
> >> 
> >> The fast-import commands are human readable, but the blob contents are
> >> included inline. I don't see how sending a binary delta is any worse
> >> than sending a literal binary blob over the stream.
> >
> > OTOH, the xdelta format is not exactly straightforward to produce, with
> > the variable length encoding of integers. Not exactly hard, but when
> > everything else in fast-import is straightforward, one has to wonder.
> 
> Unless you already have your change in the xdelta on hand, or the
> format your foreign change is in gives sufficient information to
> produce a corresponding xdelta without looking at the content that
> your foreign change applies to, it is silly to try to convert your
> foreign change into xdelta and feed it to fast-import.
> 
> What constitutes "sufficient" information?  The xdelta format is a
> series of instructions that lets you:
> 
>  - copy N bytes from offset in the source material to the
>    destination; or
>  - copy these N literal bytes to the destination.
> 
> to an existing piece of content, identified by the object name of
> the "source material", to produce a result of "applying delta".

The patch format I'm getting from mercurial boils down to:
  - replace N bytes from offset in the source material with the given
    M bytes.
Which can easily be converted to xdelta without looking at the original.

Mike