You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Stein <gs...@lyra.org> on 2003/04/04 21:40:53 UTC

bdb maintenance (was: Auto-cleaning of log files?)

On Fri, Apr 04, 2003 at 07:50:02AM -0600, cmpilato@collab.net wrote:
> Tobias Ringstrom <to...@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

Re: bdb maintenance (was: Auto-cleaning of log files?)

Posted by Jay 'Whip' Grizzard <el...@lupine.org>.
> 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.

Uhhhh ... what maintenance does CVS require?

I've been using CVS for damned near forever at this point, on some
fairly big projects, and I don't recall ever having to do, well, anything
to keep it working (beyond 'back up the filesystem').

I'm sure that there are situations where CVS needs some backend work (like
the aforementioned 'corruptions' and 'stale locks', both of which an
administrator _shouldn't_ have to deal with), but your average admin for
your average CVS install won't really need to know about any of that.

And honestly, if someone told me "unless you actively administrate this CVS
repository, it's going to grow in size extremely rapidly, without bound,"
I'd just keep on walking and find another tool. I'm sure a lot of people
would do the same for subversion.

Subversion should work -- and work reasonably well -- out of the box, for
any normalish situation into which it is placed. I think 'work reasonably
well' should probably go as far as to mean 'should not require 
administration' for the average case. 

"Work reasonably well" certainly shouldn't require regular administration
with bdb tools, especially since your average administrator will probably
fix the size 'problem' with "db_archive -a -h | xargs rm". Why make them 
go through the extra work?

-jay

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org