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...