FSFS7 introduced a new on-disk lockfile, db/pack-lock, that allows packing
a repository without completely blocking the commits. We also extended the
svn_fs_fs__hotcopy() logic to take this lock for the source repository, see
r1589284 and the related discussion [1, 2].
I think that this behavior — taking a lock in the filesystem of the source
repository — is a regression, because now 'svnadmin hotcopy' requires write
access to the source repository. One example of how this prerequisite could
break existing installations would be a system where an account performing
the backup only has read access to the source (that sounds logical to me).
Another example would be using 'svnadmin hotcopy' to import an existing
repository from something like a read-only SMB share, and an attempt to do
so would trigger an error for FSFS7 repositories.
Here is a quick reproduction script:
$ svnadmin create source
$ svnadmin create source-old --compatible-version=1.8
$ chmod -w -R source
$ chmod -w -R source-old
$ svnadmin hotcopy source target
svnadmin: E000013: Can't open file 'source/db/pack-lock': Permission denied
$ svnadmin hotcopy source-old target-old
* Copied revision 0.
Please note that the existence of db/pack-lock in the source is orthogonal to
this reproduction script. Calling 'echo "" > source/db/pack-lock' after the
first step would still trigger the same error for the FSFS7 repository.
Perhaps we should add a corresponding regression test and revert r1589284?
[1] https://svn.apache.org/r1589284
[2] http://svn.haxx.se/dev/archive-2014-07/0124.shtml
Regards,
Evgeny Kotkov
Received on 2015-06-16 20:12:58 CEST