Jim Blandy wrote:
> Branko =?ISO-8859-2?Q?=C8ibej?= <brane@xbc.nu> writes:
>
>> I'm a bit uneasy about one thing: in the "strings" table, there's no way
>> to distinguist between a PROPLIST and file contents. This means we can't
>> (consistently) check that a STRING-KEY refers to the right kind of data.
>> Do we want to have such sanity checks? If yes, we might have two string
>> tables instead, one for PROPLISTs and one for CONTENTS.
>
>
> Well, keep in mind that you can't check the form of a stored proplist
> until after you've done all your delta reconstruction.
Yah, forgot about that. And, as Karl says, if the key is wrong we're out
in the blue anyway.
>> As I mentioned before, I've been searching for articles about delta
>> composition. It turns out I was a bit too optimistic about the
>> results. It looks like we'll have to invent the wheel again, or at
>> least spokes ... So, again, if anybody has any ideas, please yell.
>
>
> I talked about this with Karl on the phone, and gave pretty bad
> explanations of my thinking; I'll try to do better today. This will
> also provide some background for other readers.
[...]
I'll think about this a bit. Surely it should be possible to optimise a
composed vdelta?
This gives me an idea: When we're retreiving a revision that's more than
one step away from the head, we could replace its representation with a
delta to the current fulltext. It's even possible the combined delta is
smaller than the original, and there's no reason we can't have several
references to the same (fulltext) node. (post-1.0: write a repository
compaction tool that minimizes the number of delta compositions needed
to retreive a node, and finds the smallest possible deltas for the
representation).
--
Brane �ibej
home: <brane_at_xbc.nu> http://www.xbc.nu/brane/
work: <branko.cibej_at_hermes.si> http://www.hermes-softlab.com/
ACM: <brane_at_acm.org> http://www.acm.org/
Received on Sat Oct 21 14:36:29 2006