Karl Fogel wrote:
> Greg Hudson <ghudson@MIT.EDU> writes:
>
>> Well, perhaps we should be cautious. But I think polishing the vcdiff
>> generator and writing a vcdiff parser would be a lot harder than
>> writing a generator and parser for the simpler format.
>
> Yah. I think we should hear from Branko before deciding, but you
> might be right...
>
> Branko, thoughts?
In no particular order:
* What my envoder is (supposed to) do is generate vcdiff windows
using a subset of coding table 0, which is about half of what
vcdiff is (supposed to be) capable of. It's also far from being
fully functional.
* The vcdiff format can in theory support very compact output (since
you can generate optimized instruction tables), but actually
writing code that implements all of the features is IMO not
trivial. I'd compare it to a simple optimizing compiler -- not
rocket science, granted, but probably more than SVN needs right now.
* Vcdiff isn't used anywhere, as far as I know; what are we trying
to interoperate with?. What's more, the Internet Draft describing
it has expired and I haven't found any follow-up. This may or may
not be significant.
* In fact, I'm not aware of *any* industry-standard binary delta
format. Hmmm. Probably a deficiency on my part. Does xdelta count
as industry-standard?
* Greg's proposal would give us a usable binary delta format and
should be very straight-forward to implement (he could also re-use
some of my vcdiff code).
* It's entirely possible that it'll take him less time to implement
his format than to finish up even the rudimentary vcdiff encoder.
* The vdelta paper, besides giving a short (incomplete) description
of the vdelta algorithm, also describes an encoding format for
vdelta. It might make sense to take a look at that. see if it's
useable.
* As you (Karl) say, we'll have support for other delta formats
later on, anyway.
/Summa summarum/: Greg should go ahead and implement his simpler proposal.
In fact ... call me an idiot, but I feel that with a bit of work, it
could be a pretty good alternative to vcdiff. We might even want to
write up an Internet Draft one we've had some experience with the format.
That's my EUR0.02.
--
Brane C(ibej
home: <brane_at_xbc.nu> http://www.xbc.nu/brane/
ACM: <brane_at_acm.org> http://www.acm.org/
Received on Sat Oct 21 14:36:10 2006