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

Re: Reverse-delta storage

From: Karl Fogel <kfogel_at_collab.net>
Date: 2001-04-19 23:19:42 CEST

Branko Čibej <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.
>
> The rest seems fine.

At first, I thought: yes, it might be a good idea to use two tables:
`strings' and `skels' (or perhaps `strings' and `lists'). The second
table would hold proplists and dir-entries-skels.

Then, I thought:

There isn't in general any reliable way to distinguish between a skel
string and a non-skel string. If you happen to have a string that
looks like a skel, then if you apply some "is_skel" test to it, the
test will return true, even though maybe it just happens to be a file
contents that looks like a skel.

So no matter what we do, we'll be relying on using the right key.
Either we got the value from a `lists' table, in which case we'd
better hope we didn't accidentally store a contents string there, or
we got the value from the `strings' table, in which case we'd better
hope our key was right. (Or vice versa, you know.)

Well, if the key is wrong, then we're not *really* getting much
insurance from the fact that we're at least grabbing the value from
the right table. Correctly parsing the wrong skel is not a better
error than either a) returning a parse error because a string is not a
well-formed skel, or b) correctly parsing the wrong skel :-). And at
least in scenario (a), we'll detect the error sooner.

So we might as well just put them all in strings.

> 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've some ideas, actually; will be committing them to fs-improvements
forthwith.
Received on Sat Oct 21 14:36:29 2006

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