Philip Martin <philip.mar...@wandisco.com> writes: > Ben Reser <b...@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*
