On 02/15/2012 11:05 AM, Philip Martin wrote:
Stefan Sperling<s...@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
