Harry Bullen wrote on Wed, Feb 15, 2012 at 12:03:15 -0500:
> On Wed, Feb 15, 2012 at 6:24 AM, Stefan Sperling <stsp_at_elego.de> wrote:
> > On Wed, Feb 15, 2012 at 03:02:04AM +0200, Daniel Shahaf wrote:
> >> Stefan Sperling wrote on Tue, Feb 14, 2012 at 23:19:58 +0100:
> >> > Until then, svnsync or svnadmin dump/load are the only officially
> >> > supported incremental backup solutions. But, as Daniel explained,
> >> > 'rsync' followed by 'svnadmin recover' produces valid copies of
> >> > FSFS repositories, too.
> >>
> >> I didn't say that, Stefan, since it's not true. rsync is not safe if
> >> the SQLite db is being read or written whilst rsync runs.
> >
> > Ah, true. I keep forgetting about the rep cache...
> > I'm sorry if you felt I was mis-attributing this to you.
> >
> > All I can say in my defense is that the whole point of adding incremental
> > hotcopy support (which of course handles the rep-cache properly) was to
> > finally stop worrying and forget about such details :)
>
> Thank you for this advice. From what I gather rep-cache.db, can be
> regenerated by svn. If I used rsync and excluded the rep-cache.db
> would I then want to run 'svnadmin recover' on these backup or is
> rep-cache.db regenerated automatically when the repository is used?
Yes and no. The data for new revisions will be written if fsfs.conf is
configured to enable the cache. The data for old revisions won't be
backfilled, but it's certainly possible to do so (by walking all the
node-revs and adding their reps to the table), but I don't know that
anyone has actually written the code to do so.
Received on 2012-02-15 18:45:49 CET