> Reading the comments to svn_delta_op_t, I noticed the restriction that
> a copy from the source to the target (the svn_delta_source op) can't
> cross the source/target boundary. Neither the Vdelta algorithm nor the
> vcdiff format have that restriction. Was this meant to make it easier
> to stream the source and target data?
I ignored that trick from the papers because:
- it makes the window format easier to describe and (it seems to me)
understand,
- the ability to use substrings that happen to cross from the end of
the source string onto the beginning of the target string seems
obscure, and unlikely to provide any significant additional
compression, and
- it seemed to me that the virtual concatenation could make delta composition
more complex (although I'm not sure about this).
Perhaps there is some common case that I'm misunderstanding, but
concatenating the source and target seems to me more obscure than
significant. Maintainability is more important.
But that's just the way the scales happened to tip for me. If you
prefer doing things otherwise, that's fine.
I don't think it will make streaming more or less difficult. The
vdelta algorithm must process the entire source string before
producing its first opcode anyway. But the person writing the delta
generator is in the best position to answer that question.
Would you prefer an interface closer to vdelta/vcdiff, in which there
are only two opcodes, one of which copies from the virtual
concatenation of the source and the target strings? If that's easier
to work with, then I think it's fine to change the interface.
> > We'll be adding to this interface over time, but I think everything
> > needed to talk to a basic delta engine is there.
>
> May I suggest a small change: s/ap_off_t/apr_off_t/g .
Yes, thank you.
> This brings me to another question I've been meaning to ask. Is it
> safe to assume we'll be using the APR library throughout the code?
> I noticed a copy of glib is in the repository, too. APR and glib
> overlap in several places. Which is preferred?
We're going to ditch glib presently. We're not using it.
Received on Sat Oct 21 14:36:06 2006