First impressions...

        I'm not going to do much development, I have a lot of other
things to work on. But, I think this project is very interesting, and I
thought I'd say some things that struck me as soon as I played with it.
There are positives and negatives.

Positives

The meta-data idea is excellent. Files in a version control system need
more meta-data than the filesystem provides. Of course, RCS provides
this too, but has less of a clear concept of what it's doing.

Directory versioning is an excellent idea, and is big part of why fairly
complex meta-data is required.

I had no idea the CVS protocol was so horribly ugly until I read your
page. Cleaning it up is an excellent idea.

Following CVS model is also a good idea. There's a reason CVS is
incredibly popular. Complex enough to be useful, simple enough to be
easy to set up and implement almost anywhere.

Atomic updates critical, and I'm happy you're doing them.

I'm kind of short on my explanations of the positives, because I presume
you specificall designed them in, and already have a clear idea of why
they're good. :-)

Negatives

Using Berkeley DB extensively is a bad idea. Plain text files much more
readable. Keep seperate revisions in seperate files or seperate
directories. Take advantage of the filesystem as a database. Using
Berkeley DB essentially creates an extra superfluous namespace. Try
reading reiserfs naming system docuement
(http://www.namesys.com/whitepaper.html) to understand why this is a bad
idea.

Having a single tree version number is bad too. It becomes harder to
get an intuitive sense of changes to individual files. It's also hard
to create merged trees this way. Especially if tags just refer to a
partiular tree version number.

I think having structureless version numbers may be a bad idea. It's
useful to know, at a glance, which versions belong to which branch, and
to be able to see the branch history of a file in its version history.
Taking information out of version number just removes it from clear view
and makes you have to look somewhere else for same info. Just because
CVS had structured version numbers as a side effect of it's kludgey
implementation in terms of RCS doesn't mean they're evil.

Controlling subversion behavior based on MIME types may be a bad idea.
The 'type' of a file isn't that important to a version control system.
It mostly wants to know which diff and merge technique to use, and what
kind of transformation is needed to accurately move between the database
representation and the client side representation. I suspect that MIME
type is not a good match. For example most source code would be
text/plain, but LISP source would be best served by a diff that was
aware of LISP's easily parsed expression syntax, not by some arbitrary
delimeter like lines or words that has nothing to do with the structure
of the language.

WebDAV? Why? Seems like adding a useless layer to me. Lets replace
the very simple xinetd with a much more complex Apache, and add an extra
superfluous protocol layer as well! OSes that make writing to a socket
somehow different from doing any other kind of IO deserve to have it be
complicated to port stuff to them. Luckily, you were farsighted enough
to make this easy to change if someone gets irritated enough by it.

Actually the other problem with WebDAV is an added dependency on Apache.
The hardest part about compiling your system is getting it to find
Apache, and having the right version of Apache around.

All in all, I think you have a very interesting, and potentially useful
thing here. Thank you all for your work.

Have fun (if at all possible),

-- 
"It does me no injury for my neighbor to say there are twenty gods or no God.
It neither picks my pocket nor breaks my leg."  --- Thomas Jefferson
"Go to Heaven for the climate, Hell for the company."  -- Mark Twain
-- Eric Hopper (hopper_at_omnifarious.org  http://www.omnifarious.org/~hopper) --