Greg Hudson <ghudson@MIT.EDU> writes:
> 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.)
A related (but not urgent) blue-sky point that may affect our thinking
about FSFS:
We've talked a bit about "svn submit" as a more tentative version of
"svn commit", whereby one would create a txn but not commit it.
Someone else could then review the txn, and promote it / reject it /
promote to a branch / whatever. So I think it's fine if txn purging
is a client responsibility, but would worry if txn purging were ever
required or enforced by the server-side. You don't seem to be
suggesting the latter; I just wanted to mention this now, so we think
about txns as potentially first-class, user-visible objects.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 14 17:08:53 2004