subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vallon, Justin" <>
Subject RE: Support for filesystem snapshots (?)
Date Tue, 03 Aug 2010 15:19:43 GMT
(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.


-----Original Message-----
From: Vincent Lefevre [] 
Sent: Tuesday, August 03, 2010 8:03 AM
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 <> - Web: <>
100% accessible validated (X)HTML - Blog: <>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

View raw message