Recently, Red Hat Enterprise Linux 5 updated its Subversion package
from 1.5.x to 1.6.11.

This exposed a *forwards* compatibility problem: the Subversion 1.6
hotcopy command fails on Subversion 1.5 repositories:

$ svnadmin hotcopy test-repo test-repo.HOTCOPY; echo $?
svnadmin: Can't open file 'test-repo/db/fsfs.conf': No such file or directory
1

We tested if creating an empty db/fsfs.conf file will resolve this
issue, and it does.  And this issue seems to have been fixed in 1.6.13.

But given that this very simple compatibility issue wasn't caught
until two bugfix releases later, we're concerned that there may be
other forwards compatibility issues that will bite us in the future.
Therefore, we've decided to dump and restore all of our Subversion
repositories, to bring them up to Subversion 1.6 db backends.

Question: if I "svnadmin dump" a repository, is it safe to allow
read-only access to the repository while the dump is in progress?  Or
is it the case that permitting even read access could interfere with
the "svnadmin dump" operation?

I ask because it will take a non-trivial amount of time to perform
svnadmin dump/load operations on all of Subversion repositories.  If
we can at least permit read-only access while this upgrade is in
progress, that will have much less of an impact on our users then it
we have to block all access during the upgrade...

Reply via email to