On 17 March 2014 03:09, <stef...@apache.org> wrote: > Author: stefan2 > Date: Sun Mar 16 23:09:45 2014 > New Revision: 1578176 > > URL: http://svn.apache.org/r1578176 > Log: > Model the FSFS pack lock similarly to our other file based locks in FSFS. > This gives us proper mutex functionality should multiple threads try to > pack the same repo at the same time. > > * subversion/libsvn_fs_fs/fs.h > (fs_fs_shared_data_t): Add a thread mutex alongside the file lock. > > * subversion/libsvn_fs_fs/fs.c > (fs_serialized_init): Initialize the new mutex. > > * subversion/libsvn_fs_fs/fs_fs.h > (svn_fs_fs__get_lock_on_filesystem): Privatize again. > (svn_fs_fs__with_pack_lock): New lock handling function similar > to what we do for the other locks. > > * subversion/libsvn_fs_fs/fs_fs.c > (path_pack_lock): New utility function. > (svn_fs_fs__get_lock_on_filesystem): Rename back to ... > (get_lock_on_filesystem): ... this again. > (with_some_lock_file): Update caller. > (svn_fs_fs__with_pack_lock): Implement the new lock function. > > * subversion/libsvn_fs_fs/pack.c > (svn_fs_fs__pack): Use the new pack lock handling function. > > Suggested by: ivan > Hi Stefan,
Thanks for reworking this. But with new code is more clear that separate pack lock break concurrent svnadmin hotcopy: hotcopy operation only takes write-lock, not taking pack-lock. Thus we Subversion hotcopy operation may copy partially packed repository. -- Ivan Zhakov CTO | VisualSVN | http://www.visualsvn.com
