[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:16:43 CET

On Sat, 9 Feb 2002, Branko [UTF-8] ÄŒibej wrote:

> Daniel Berlin wrote:
>
> >On Fri, 8 Feb 2002, Daniel Berlin wrote:
> >
> >>One thing we should also be doing is fulltext compression. Rather than
> >>give up, or store full fulltexts, we could at least delta them against an
> >>empty string.
> >>Since vdelta is based off lempel-ziv, it'll give you some compression
> >>(better than compress, worse than gzip, according to the paper).
> >>
> >>Right now, we just leave it completely fulltext.
> >>
> >Strike that.
> >
> >I forgot the compression comes mainly from their encoding/folding, rather
> >than anything else.
> >Since we do neither, ...
> >
> 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.
--Dan

---------------------------------------------------------------------
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.