Re: svn_fs_node_created_rev applied to transaction root differs between FSFS and BDB

On Mon, Sep 11, 2006 at 02:13:49AM -0400, David Glasser wrote:
> At the low level, it comes down to creating a new repo and running:
>
> SVN_ERR(svn_repos_fs_begin_txn_for_commit(&txn,
> repos,
> 0,
> "someuser", "log",
> spool));
> SVN_ERR(svn_fs_txn_root(&txn_root, txn, spool));
> SVN_ERR(svn_fs_node_created_rev(&rev, txn_root, "", spool));
>
> "rev" is 0 on BDB and SVN_INVALID_REVNUM on FSFS.
>

According to the documentation for svn_fs_node_created_rev():

/** Set @a *revision to the revision in which @a path under @a root was
 * created. Use @a pool for any temporary allocations. @a *revision will
 * be set to @c SVN_INVALID_REVNUM for uncommitted nodes (i.e. modified nodes
 * under a transaction root).
 */

> And that's as far as I got. Questions:
>
> * Who's right, BDB or FSFS? I assume BDB since its result doesn't lead
> to the dirprop conflict bug.
>

I wouldn't assume either. Does creating a new transaction conceptually
cause the transaction's root to be immediately modified? If the answer
to that question is yes, FSFS is right; if no, BDB is right.

Of course, as soon as you actually change the transaction (other than by
setting revprops), the transaction root will be guaranteed to be modified,
and so the function will always return SVN_INVALID_REVNUM for the root
from then on.

I assume that BDB does actually return SVN_INVALID_REVNUM for the root
once the transaction is modified?

I'm surprised that our out-of-dated-ness checks are dependent on what
appears to be very much a corner case - whether an unmodified transaction
has a modified root. Where's the code that's actually checking this?

Regards,
Malcolm

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Sep 11 13:21:31 2006