Re: [9fans] Changelogs & Patches?

["Roman V. Shaposhnik" <rvs@sun.com>]

On Mon, 2009-01-26 at 08:22 -0800, Russ Cox wrote:
> > As for me, here's my wish list so far. It is all about fossil, since
> > it looks like venti is quite fine (at least for my purposes) the
> > way it is:
> >     1. Block consistency. Yes I know the argument here is that you
> >     can always roll-back to the last known archival snapshot on venti.
> >     But the point is to kown *when* to roll back. And unless fossil
> >     warns you that a block has been corrupted you wouldn't know.
>
> I don't understand what you mean.  Do you want fossil to tell
> you when your disk is silently corrupting data, or something else?

Implementation vise I would be happy to see the same score checks that
venti does implemented in fossil. Complaining like this:
   seterr(EStrange, "lookuplump returned bad score %V not %V", u->score, score);
Would be good enough.

> >     2. live "mounting" of arbitrary scores corresponding to vac
> >     VtRoot's to arbitrary sub-directories in my fossil tree. After
> >     all, if I can do "create" of regular files and sub-directories
> >     via fossil's console why can't I create pointers to the existing
> >     venti file-hierarchies?
>
> The only reason this is hard is the choice of qids.
> You need to decide whether to reuse the qids in the archive
> or renumber them to avoid conflicts with existing qids.
> The vac format already has a way to offset the qids of whole
> subtrees, but then if you make the tree editable and new files are
> created, it gets complicated.

I see. Thanks for the explanation.

> >     3. Not sure whether this is a fossil requirement or not, but I
> >     feel uneasy that a root score is sort of unrecoverable from the
> >     pure venti archive. Its either that I know it or I don't.
>
> I don't understand what you mean here either.
> From a venti archive, you do cat file.vac to find
> the actual score.

As I mentioned: this one is not really a hard requirement, but
rather me thinking out loud. To me it feels that Venti is
opaque. In a sense that if I don't know the score to give to flfmt -v
then there's no way to browse through the venti to see what
could be there (unless I get physical access to arenas, I guess).

Now, suppose I have a fossil buffer that I constantly snap to venti.
That will build quite a lengthy chain of VtRoots. Then my fossil
buffer gets totally corrupted. I no longer know what was the
score of the most recent snapshot. And I don't think I know of any
way to find that out.

> The amazing thing to me about fossil is how indestructable
> it is when used with venti.

I agree. That has been very much the case during my short
evaluation of the two.

> > It is actually quite remarkable how similar the models of
> > fossil/venti and Git seem to be: both build on the notion
> > of the immutable history. Both address the history by the
> > hash index. Both have a mutable area whose only purpose
> > is to stage data for the subsequent commit to the permanent
> > history. Etc.
>
> I don't think it's too remarkable.  Content hash addressing was
> in the air for the last decade or so and there were a lot of
> systems built using it.  The one thing it does really well
> is eliminate any worry about cache coherency and versioning.
> That makes it very attractive for any system with large
> amounts of data or multiple machines.  Once you've gone down
> that route, you have to come to grips with how to implement
> mutability in a fundamentally immutable system, and the
> obvious way is with a mutable write buffer staging writes
> out to the immutable storage.

All true. Yet, it is surprising how many DSCMs that were built
on the idea of hash addressable history got the "implementation
of mutability" part wrong. Git is the closest one to, what I
now understand, is the fossil/venti approach.

Thanks,
Roman.