I can reproduce this problem under Linux, fortunately, so I know what's
going on.
On Wed, 2004-05-12 at 22:56, D.J. Heap wrote:
> Some more info on this -- the commit actually succeeds and the
> repository seems to be fine. However, a second DELETE for the activity
> comes through and fails because the transaction directory has already
> been removed. The 2nd DELETE doesn't happen with fstype=bdb.
I think you misinterpreted slightly. The first DELETE request fails
with FSFS when it tries to open the transaction, since svn_fs_commit_txn
invalidated the transaction ID. That's the real source of the error. A
second DELETE request comes in when the client sees close_edit() fail
and invokes abort_edit().
In BDB, opening the transaction after committing it succeeds; the
attempt to purge the transaction fails with
SVN_ERR_FS_TRANSACTION_NOT_MUTABLE, which mod_dav_svn catches and
ignores.
> It kind of seems like a client problem, but I don't know how the client
> could know the difference? Or can DELETE's be initiated without the
> client somehow?
The client is behaving just fine from a DeltaV perspective, which is
good because we couldn't rely on a client-side fix anyway. After much
consideration, I think the correct solution is to:
* Clarify what happens to the txn ID after a successful commit, in the
svn_fs_commit_txn docstring. (Exactly what we should say is open to a
little bit of debate. Certainly, one should not expect to be able to
write to the transaction, since the txn becomes immutable under BDB.
But one should be able to open it, and attempting to purge it should
either succeed or yield a predictable error.)
* Change FSFS not to purge the transaction on svn_fs_commit_txn. We
can either leave it alone, assuming that the caller will re-open and
purge the transaction, or we can gut it but leave the transaction
directory around, much like a zombie Unix process, so that it can be
opened and finished off.
* Change the libsvn_repos commit editor to re-open and purge the
transaction after committing it. (The re-open is necessary because
svn_fs_commit_txn is documented as invalidating the txn object, though I
don't know if there's a good reason for that.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 14 03:06:35 2004