On Tue, 28 Sep 2004 10:01:50 -0700, Raye Raskin <firstname.lastname@example.org> wrote:
> > From: "Dave Neary" <email@example.com>
> > There are of course other ways to obtain the same result - by backing up
> > all of the berkley DB transaction logs before deleting them, you can (in
> > principle) rebuild an entire Berkley database without even having
> > subversion on there by replaying all the transactions. This also gives a
> > way to do an incremental back-up - you are only backing up the most
> > recent DB log files.
> Still new to svn, but here's a thought. Looking in my very simple
> test repository, and based on the name of the log files I see there,
> it looks like new log files may be generated from time to time. Too
> bad, because it would have been simple, using softlinks, to keep the
> log files on another filesystem otherwise. Is there a configuration
> option someplace that controls where to put the log files?
"The database environment's logging directory may also be set using
the environment's DB_CONFIG file. The syntax of the entry in that file
is a single line with the string "set_lg_dir", one or more whitespace
characters, and the directory name. Because the DB_CONFIG file is read
when the database environment is opened, it will silently overrule
configuration done before that time."
Not sure the procedure for switching it over though. You should
experiment with a test repo first.
> If there WERE a way to create them in another filesystem, then would
> they not actually serve as online backup files? Of course you need
> to have 100% faith in the logging and restoring capabilities of the
> log files (from my own experience I know this can be problematical.)
> Just don't delete the log files until you've done a complete backup
> of the repository.
It should work, yes. You need all the log files ever created in the
repository (turn off logfile autoremoving), or a set of db files and
all log files active at the same time as the copy or later. You may
also have to use manual catastrophic recovery, using db_recover. See
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed Sep 29 01:29:19 2004