(c) is an automatic hands-off recovery, either by just having the recovery logic know how to clean up (delete stale files) or making the recovery logic transparent (overwrite files). This would be possible where locks are managed by the kernel/filesystem which "knows" when a process dies, and can release and pass a lock on to the next waiting locker.
(b) is a case where you have to issue an "svnadmin cleanup-lock" kind of command (don't know if you need to). If the svn repo filesystem uses lock files (touch svnrepo/mylock), then killing the process (kill -9) will not automatically remove the lock, and user intervention will be required to delete the lock file. This is the case for rcs-locks, svn-sandbox locks, lockfile(1) locks. -- -Justin -----Original Message----- From: Vincent Lefevre [mailto:vincent-...@vinc17.net] Sent: Tuesday, August 03, 2010 8:03 AM To: users@subversion.apache.org Subject: Re: Support for filesystem snapshots (?) On 2010-08-02 14:41:29 -0400, Vallon, Justin wrote: > That is the situation I raised. If the network connection between > the host that is modifying the repository and the filesystem that > houses the repository is lost, will be repository be (a) corrupt, > (b) require cleanup (locks, etc), (c) pristine? > > (c) is great > (b) is ok > (a) means the operations are not transactional > > Further: > > (c) snapshots work > (b) snapshots work, but need a cleanup after restore > (a) snapshots don't work; repository is not transactional, either I don't see how (c) could be possible, as a commit requires several filesystem operations (even for updating "current"). Of course, (b) + automatical clean-up could look like (c). -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <http://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)
