> Perhaps I'm misunderstanding -- Branko doesn't actually generate
> vcdiff format data, right?
Ah, let's back up a bit and make things more clear. I was assuming
you had read the note I forwarded from Branko when you said you
weren't particularly wedded to the vcdiff format.
The big patch I forwarded earlier this morning is Branko's
implementation of a vcdiff generator. By his own appraisal, it's not
polished or particularly commented, and there's no corresponding
parser--which in some respects is the harder half of the job, since
the generator uses only a subset of the features of the format. And
I'm worried that it might be difficult to maintain the generator given
the sheer quantity of magic vcdiff knowledge is embedded therein.
(For instance, it involves a pair of perl scripts to generate
instruction code tables, and even the higher-level of the two perl
scripts includes a bunch of magic numbers which only mean anything if
you have a detailed understanding of the vcdiff format.)
Which isn't to say Branko did a bad job; he ran out of time to finish
things up, and he was implementing a spec which was much more
complicated than I think anyone else realized. But my reaction upon
reading the implementation is "my god, this is about ten times more
goo than we really want; I never realized vcdiff was this gross."
> If we did have true vcdiff output being generated already, then we
> should be a lot more cautious about abandoning the format.
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.
Received on Sat Oct 21 14:36:10 2006