[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Removing unused logs

From: Vladimir Berezniker <vmpn_at_hitechman.com>
Date: 2003-11-03 18:51:23 CET

This email did not seem to make it to dev list. So I am sending it for the
second time...

<quote who="C. Michael Pilato">
> "Sander Striker" <striker@apache.org> writes:
>> Hi,
>> In #1571 there is a patch that provides us with svnadmin hotcopy:
>> svnadmin hotcopy [--cleanlogs] SRC DEST
>> The patch is looking good, but I have some questions regarding
>> the pruning of logs.
>> The command comes with an option --cleanlogs, which removes the logs not in
use anymore from SRC.

The copying algorithm:

1. Hotcopy makes a regular file copy of repository with exception of content in
/db and /locks. Lock files in /locks for DEST will be created on the first use.

2. /db copied according to Berkeley DB hot copy procedure.

3. Recovery is executed on DEST to ensure working copy.

4. Cleanup on log files in SRC is performed. NOTE: Some log file that just
became unused might remain. See detailed explanation of cleanup below.

>> Now, I can see why it would do that.
>> I'm wondering if it should remove the logs from DEST aswell, or not to touch
it. Basically, what if I want to clean the logs from DEST, am I back to
using svnadmin lsdblogs | xargs rm?
>> Or should be grow a command cleanlogs, which does what the --cleanlogs option
to hotcopy does? If we do that, the user can decide when to clean out logs
(without requiring a hotcopy), safely all the time. Then there is also the
option of the user using svnadmin cleanlogs on DEST. hotbackup.py can use
svnadmin hotcopy SRC DEST, followed by svnadmin cleanlogs SRC to maintain
current behaviour.
> If we treat as special generic log file cleanup, then we should also provide a
subcommand to relocate unused logs elsewhere (for backup purposes). But this
is just silly. The removal and relocation of logfiles can be done just fine
with xargs or with a custom wrapper script (for those on xargs-impaired OSes).
 We don't need to promote every permutation of every command-line operation to
a first-class subcommand.
> So:
> +0 on --cleanlogs removing logs no longer in use by the DEST
> repos from SRC repos (that is what the option does, right)?
To clarify, hotcopy paranoid algorithm does the following when cleaning the log

--cleanlogs causes a function called svn_fs__clean_logs from libsvn_fs to be
called. It does the following:

1. All unused log files in SRC are enumerated.

2. If a 100% identical copy (byte by byte check) of the log file exists in DEST,
then the unused log in SRC is deleted.

This is to ensure that only the logs that were sucessfully successfully copied
and have not changed, while the operation was in progress, were deleted.

> This insures th at the subcommand never removes logs from SRC that it
doesn't have a copy of in DEST. We don't strictly need this option at
> -1 on --cleanlogs removing that same set of logs from the DEST
> location. I'd like to guarantee that if you never removed logs by any
external means, running 'svnadmin hotcopy
> --cleanlogs' routinely on your repository will a) keep your live repos
log count as low as safely possible, and b)
> produces a set of backups from which every log file necessary for
catastrophic recovery can be gleaned.
> -1 (no veto) on 'svnadmin cleanlogs'

NOTICE: The hotcopy command will *NOT* copy files in /db and /lock folder that
do not belong to subversion. So don't store you missiong critical files there
:), please.

P.S. It seems that somehow this mailing list is being harvested by spam bots. I
started receiving spam and this email is not published in public anywhere except
this list. Not complaining, just wanted to alert everyone.

Vladimir Berezniker

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 3 19:42:21 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.