[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: Branko Čibej <brane_at_xbc.nu>
Date: 2002-02-09 22:46:55 CET

Daniel Berlin wrote:

>>>>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.
>
Sorry, you lost me here. I'm stupid tonight. Could you explain, in
simple terms even I can understand, how this would wotrk?

Thanks.

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

-- 
Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
---------------------------------------------------------------------
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.