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