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
