[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 20:17:16 +0000

Philip Martin <philip.martin_at_wandisco.com> writes:

> Ben Reser <ben_at_reser.org> writes:
>> On 2/24/14, 11:10 AM, Philip Martin wrote:
>>> 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.
>> So remove the locks as part of creating a new file. Even if the commit fails
>> for whatever reason and you remove locks that's not a problem. You were
>> ignoring those locks anyway.
> Yes, that might work, we would probably need to check added directories
> as well as added files. We would need to do it during the final stage
> of the commit when converting the transaction to a revision. We could
> also check when adding a node to a transaction but that is not
> sufficient because even if no no lock exists at that point a file could
> get added/locked/deleted before the transaction completes.

We must do part of this already, since these phantom locks cause commits
to fail.

We can't simply fail all adds when a lock exists since we need to be
make sure replace works:

   svn lock wc/f
   svn rm wc/f
   touch wc/f
   svn add wc/f
   svn ci wc

Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Received on 2014-02-24 21:17:49 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.