[PATCH 1 of 6 RFC] radixlink: introduce a new data structure

[Jun Wu]

Excerpts from Martin von Zweigbergk's message of 2017-06-02 10:38:08 -0700:
> [...]
> Would good to say here what the radix/base is (16, IIUC).

Will do.

> > +    @property
> > +    def truthoffset(self):
> > +        """position of the append-only source of truth the index contains"""
> > +        if len(self.indexdata) >= self.indexheader.size:
> > +            return self.indexheader.unpack_from(self.indexdata)[0]
> > +        return 0
> 
> Looks like this is just metadata that radixlink doesn't care about.
> Would it be hard to fit general metadata in there?

Do you have ideas about what metadata will we have?

I'm not very comfortable with the index header part either. Now I think
about it more, the header usually has a same logic concept (revision number
or file offset) like values stored in the linked list. Therefore it seems
cleaner to just move the special header to the linked list so the index file
becomes free of unnecessary parts.

For general purposing, the fact that this is a map provides some flexibility
already (use non-conflicted keys for extra metadata). Sometimes we may want
strings (ex. nodes) in the linked list.  That's doable by having another
append-only file and let the linked list point to it.

I have also thought about versioning. This is used in .hg/cache. It seems we
can just rename the cache file if there are format changes.

In V2, I'm implementing the full class in C (instead of just the "get"
method) to cut down minor overheads. So I'd prefer simplicity for now.

> > +rl1.destroy()
> 
> Hmm, you destroy it here, but then you use it just after. Maybe it
> should be called clear()?

Good idea. It'll be called "clear".