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

Re: Whither delta combiner

From: Daniel Berlin <dan_at_dberlin.org>
Date: 2002-02-09 22:34:05 CET

> >>Not at all. Vdelta itself compresses. That has nothing to do with the
> >>encoding of the block-copy instructions.
> >>
> >
> >Yes,yes, i remembered it runs over the target too.
> >
> >But turning everything into a delta (fulltexts = delta against empty
> >string) would mean we'd never need to worry
> >about fulltexts. If fulltexts simply became deltas against the empty
> >string, then everything becomes a delta combination problem.
> >
> >We'd effectively just make sure delta chains don't become too long for a
> >given revision, by combining deltas until the chain of deltas necessary
> >for a given revision was < N or something.
> >
> >Not sure if that's better or worse.
> >
> Oh, runnung a compress-only vdelta at checkpoints would definitely be
> better than storing fulltexts.
Here's the thing though, you'd never need to run a compress-only vdelta.

If the original is stored as a compress-only vdelta, then checkpoints are
just combined delta of all previous deltas.
The combined delta would have all the previous deltas, including the
delta against the empty string, and thus, be able to regen from the empty string.

Assuming delta combination is faster than generating the deltas(even if
not algorithmically, if the constant is lower) , this would be a win in
speed terms too, not just space terms.

Otherwise, it's a lose.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:06 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.