[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Lock non-existent to allow reserving a path

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Mon, 24 Feb 2014 19:10:10 +0000

"C. Michael Pilato" <cmpilato_at_collab.net> writes:

> On 02/24/2014 01:56 PM, Philip Martin wrote:
>> There is a way to create such locks at present: checkout, lock a
>> file, delete the file or parent directory, commit with --no-unlock.
>> We have a regression test for this:
>> lock_tests.py:deleted_path_lock. (Possibly this behaviour could be
>> considered a bug, perhaps 'commit --no-unlock' should remove the
>> locks on deleted files, but implementing that would be hard.)
> That behavior *is* a bug that someone must have decided post-facto
> might
> be useful. But hey, I'm not pointing fingers. That approach has
> brought us such awesome features in the past as "file externals".
> Oh.
> Wait.

It's hard to fix. Commit and unlock are separate filesystem operations
and the server can always die, or fail the unlock, after the commit. I
suppose a new filesystem might have a commit-and-unlock operation but
how could FSFS solve it? We might be able to make FSFS ignore the lock
if the file has been deleted, but that just postpones the problem until
another commit recreates the file.

Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Received on 2014-02-24 20:10:51 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.