[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: vcdiff generator status?

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2000-09-13 06:24:31 CEST

Jim Blandy wrote, regarding efficient reversal of diffs:
> But Josh MacDonald says he was doing it in his XDelta Filesystem, so
> I wanted to provide an interface at which we could plug things in.

libxdelta doesn't appear to export any interface for reversing deltas,
and neither does libxdfs. I remain skeptical that there is anything
productive you can do with a delta other than apply it to a source
stream. I'd want to see what Josh MacDonald said.

> But, the original question was: why do we need the text delta window
> data structure? It's the general principle of trying to choose the
> right representation at each level.

So, creating a "right representation" for memory storage of a data
format makes sense when you want to operate on the data in more than
one way. For instance, a Java interpreter only wants to do one thing
with Java byte code, so it doesn't convert it to a memory
representation before running it. On the other hand, an optimizing
compiler typically has a structured internal representation of source
code because it wants to apply transformations before generating
object code.

Given that I don't think we can reverse or chain deltas except by
regenerating the source and target data and generating a new delta,
I'm not sure if there are any operations besides "application" that we
might want to apply to a delta. The only other one I can think of is
"display in human-readable format" for deltas of text files. (That's
something I don't know how to do for a vcdiff, actually, but the Hunt
paper says you can do it.)

Anyway, although I have strong suspicions that the text delta
structure may be superfluous, nobody else seems to think so, so I'll
stop arguing about that.

I'll submit proposed changes for the window format soon.
Received on Sat Oct 21 14:36:08 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.