Re: can "svnadmin dump" tolerate read-only repository access?

2011-02-28 Thread James Ralston
On 2011-02-28 at 10:49-08 David Chapman  wrote:
> A "hot copy" by definition is one that will safely allow read-only
> access while the backup is in progress.

But I asked about "svnadmin dump", not "svnadmin hotcopy".

Are you asserting that read-only repository access (in our case, via
WebDAV via mod_dav_svn) will *not* perturb a running "svnadmin dump"
operation?



can "svnadmin dump" tolerate read-only repository access?

2011-02-28 Thread James Ralston
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...