On Fri, Apr 04, 2003 at 07:50:02AM -0600, cmpilato@collab.net wrote:
> Tobias Ringstrom <tori@ringstrom.mine.nu> writes:
>...
> > The problem with the current approach is that you have to learn about
> > Berkley DB in order to use Subversion. I think that it would be great if
> > the user did not *have* to do that. Except for the log file issue the BDB
> > is invisible to the user. The log files are the only thing that sticks
> > out.
>...
> Ultimately, yes, Subversion requires that you a) know that is uses a
> given database backend, and b) know how to maintain that backend. I
> don't think it's *really* that terrible of a thing to ask of our
> users,
I don't think it is a bad thing at all. CVS requests the same sorts of
things from its administrators. It just happens that CVS has been around
longer and people know what those niggly maintenance burdens are. CVS also
looks a lot like plain old files in a hierarchy, so that helps too.
Of course, it isn't just plain old files. There *are* certain relationships
between files that must be maintained. And you must be very careful when
making a backup/restoration to ensure that you have atomically performed the
procedure w.r.t commits that were/are occurring.
And administrators also need to know aobut CVS locks and how to clear them
out. And when it is safe to do so. And they need to know about the various
forms of corruption that can occur and how to solve them. And yes,
corruption *does* occur -- I have the unfortunate pleasure of being the Nth
tier for the CVS repositories in CollabNet's hosting of SourceCast.
So, no. I don't think it is unreasonable at all for an administrator to know
that we are using BDB and the care and feeding of it. I think that we
actually quite fine in that regard, as BDB is known technology with a long
history of its needs. We just need to get the appropriate pointers and
"quick start" information into our documentation.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 4 23:37:42 2003