Re: [Gnu-arch-users] arch lkml

[Tom Lord]

    > From: Peter Conrad <address@hidden>

    > [....] A well organized blob storage format (with a library for
    > accessing it) would be capable of

    >  - serving a standard changeset tar.gz files for any contained version
    >  - serving combined changesets as Andrea has requested ("give me a 
changeset
    >    containing all changes from patch-255 to patch-512")
    >  - serving changesets containing context-free diffs (useful if you want to
    >    update an unmodified local version from a remote mirror over a slow 
link)
    >  - serving as a revision library with access to any file in any revision
    >  - answer questions like "what has changed in file x between patch-x and
    >    patch-y?"

    > Dreaming one step further you could create a kernel module for
    > serving all of this (well, at least the archive and revision
    > library) through a filesystem interface...

    > My feeling is that such a format could not only be very
    > space-efficient if done properly, but also very efficient in
    > access time even though everything would have to be generated
    > "on the fly".

I basically agree.

Two options along these lines have been an and off topics for as long
as there has been arch.

One idea is to try to use svn as the storage manager for such a setup.
They have some nasty issues that I think it will take a year or so
before they're fixed (the rapidly growing log files, the
administrative touchiness of archives, some performance issues, some
questionable semantics .....).   The choice of Berkeley DB to hold a
filesystem is a little bit questionable.   But the flip-side of any
list of such issues you want to make is that it's an official goal of
the project to make a _nice_ storage manager that is pretty close in
capabilities to what you're thinking of for arch -- so, they are going
to be working on this issues for the forseeable future.   Maybe it
makes sense to "leverage" that.  (Another issue might or might not be
license compatability -- I haven't looked into that.)

The other idea is to make a simple, portable, user-space transactional
file system DB -- the kind of DB you _wish_ svn had built in the first
place -- and then put arch on top of that.  The drawback is that its
hard to go down this path and get results rapidly.  The advantage is
that you'd be shedding all the cruft that svn has accumulated (the end
result would be smaller, simpler, and cleaner) and would be
independent from the svn goal (the version-control front-end) that
trumps and sometimes contradicts the thought that they'll make a nice
back-end DB.


-t