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

Re: [Issue 4081] incremental svnadmin hotcopy for BDB-backed repositories

From: Daniel Shahaf <danielsh_at_elego.de>
Date: Thu, 15 Dec 2011 17:24:58 +0200

cmpilato_at_tigris.org wrote on Thu, Dec 15, 2011 at 07:04:44 -0800:
> http://subversion.tigris.org/issues/show_bug.cgi?id=4081
>
>
>
> User cmpilato changed the following:
>
> What |Old value |New value
> ================================================================================
> Summary|svnadmin hotcopy, bdb-only|incremental svnadmin hotco
> | |py for BDB-backed reposito
> | |ries
> --------------------------------------------------------------------------------
>
>
>
>
> ------- Additional comments from cmpilato_at_tigris.org Thu Dec 15 07:04:44 -0800 2011 -------
> In theory, incremental hotcopy of a Berkeley DB repository can be done by
> squirreling away a base hotcopy (datafiles + logfiles), and then incrementally
> copying only (but *all* of) the Berkeley DB logfiles thereafter. The logfiles
> are designed to be such that they can be replayed in sequence to enact their
> changes to the BDB datafiles. So incremental hotcopy N+1 might copy the BDB
> logfiles which are newer than those captured in hotcopy N, then replay those
> logfile actions into the backed-up datafiles.
>
> Unfortunately, the default behavior of 'svnadmin create' is to configure BDB to
> automatically remove its unused logfiles (those whose actions have already been
> reflected in the datafiles). One would need to disable that auto-purging
> functionality for such an approach to incremental hotcopy to be viable.

That's an interesting approach. But can we do without the log files?
Is there an easy way to, given N, capture all the table rows that belong
to revisions youngest than rN?

(And would we ever need to delete DB rows from the hotcopy? The above
algorithm assumes append-only tables.)
Received on 2011-12-15 16:25:59 CET

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