Billy Tanksley <btanksley@hifn.com> writes:
> From: Tom Lord [mailto:lord@regexps.com]
>> It's simpler to implement, administer, write other tools for, inspect,
>> grok...
> All false. (Except for "implement", but I don't see you implementing a
> filesystem, either.)
I'm with Tom on this, and I think you're wrong, at least for some target
audiences. I maintain VC repositories for system administrators,
currently using CVS, and the use of a database as the backend is the
single largest difficulty with switching to SVN. I think it's an
overcomable difficulty, but it definitely makes me uncomfortable.
With a CVS repository, I can see exactly what CVS thinks the internal
state is, can backup, copy, and restore the repository using standard
tools that I use all the time like rsync rather than learning custom tools
that only work with a database that I don't use for anything else, know
that the repository can be stored on any file system and won't have any
problems with things like record locking (which AFS does not support), and
in the event of emergencies can correct problems with a text editor.
I think I can get past this and use SVN anyway, but it's a real leap of
faith. Basically, it's a substitution of an open, easily understood file
tree that if push comes to shove I can turn back into a bunch of RCS files
with a complete black box. I have to just assume that SVN will do the
right thing, and if for any reason it doesn't, I'm nearly helpless.
Sure, there are doubtless all sorts of utility programs that come with
Berkeley DB that, together with a copy of the Subversion schema, will let
me become less helpless, but only through a lot of learning and use of
tools that are unusual and special to just this situation, rather than
using the tools that I know like the back of my hand and use daily.
This is a very real and serious problem for me. It dramatically increases
the level of faith and trust that I'll have to have in SVN before I'll
entrust anything important to it; if it were using file system storage,
I'd be much more willing to try it out and see how it works at a much
earlier stage, because I could go look at the repository after I did
things and be sure that what was happening was what I expected to happen.
And that feeling only gets stronger when I see various issues like the
fast-growing archive logs that are an artifact of the database.
I have some past experience with use of Berkeley DB, with the ovdb
overview storage method in INN, so I know how it can fall over or get into
various bad lock states under high load, and while I think that it's
generally very well-written code, I *don't* trust it as well as I trust
kernel file system code. Not even close. This is nothing against the
Berkeley DB people, who I think are excellent programmers, but the file
system code has just been tested way more thoroughly, by a lot more
people, under a lot higher stress.
Now if you're coming from a background where grovelling around in a CVS
repository isn't a fairly natural and comfortable thing to do, then I can
understand why this may not be an issue for you. Or if you're really
comfortable dealing with Berkeley DB databases, all of the inspection and
correction issues that I have may be old hat to you. But please don't
underestimate the importance of this issue to some of the rest of us,
particularly those of us who chose CVS over other available options
precisely *because* it used a nice, simple, easily-browseable storage
format that was very familiar to us old RCS users.
--
Russ Allbery (rra_at_stanford.edu) <http://www.eyrie.org/~eagle/>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:04 2006