On 02/15/2012 11:05 AM, Philip Martin wrote:
> Stefan Sperling<stsp_at_elego.de> writes:
>
>> But rather than going through that effort, I would recommend using
>> svnadmin dump/load, or svnsync with file:// URLs, until Subversion 1.8
>> is released. At which point you can switch over to using
>> "svnadmin hotcopy --incremental", which will copy rep-cache.db via
>> the appropriate sqlite APIs.
>
> Are you suggesting this because you know the LVM snapshot method doesn't
> work or just because it's a method that avoids non-standard Subversion
> tools?
>
> Running rsync on an LVM snapshot looks like it should work to me. An
> LVM snapshot freezes the filesystem by diverting all writes into the
> snapshot area. A Subversion repository in the frozen filesystem may
> have transactions in progress, Subversion transactions or SQLite
> transactions, but they won't change while the copy is made. If the
> copied repository is ever used then these partial transactions will
> simply be ignored. Provided Subversion gets its fsyncs and writes in
> the correct order, and I believe it does, this looks like it should
> work. I'd go as far as saying if the copied repository doesn't work
> then this is a Subversion bug, or perhaps an LVM/OS bug.
One needs to use at least 1.6.5, there is one fsync I added to ensure
that fsfs works without causing empty revprop files. This was seen on a
GPFS filesystem [1].
Blair
[1] http://subversion.tigris.org/issues/show_bug.cgi?id=3442
Received on 2012-02-20 01:10:19 CET