On Mon, Sep 11, 2006 at 05:07:57PM -0400, David Glasser wrote:
> It seems like this, as well as delete_entry and open_file in that
> editor, are relying on "an invalid created_rev means we've already
> decided it's not out of date", which seems reasonable enough to me. So
> I do feel like FSFS is at fault
>
I completely agree (and I do also agree that it'd be good to document that
assumption, as well as the reliance on the fact that SVN_INVALID_REVNUM
is always less than a valid revnum).
Unfortunately, I don't have the time to look at this myself at the moment.
You mentioned the DAG layer earlier, which I've always ignored, since
it's a fairly thin layer of abstraction over the FSFS implementation
(and one that I believe someone - ghudson? - suggested should really be
removed at some point).
If I was doing this... I think it would break too much to initialise
the transaction's id with the base revnum (and you'd also need
to set it to INVALID once it'd been changed), so I'm guessing that
svn_fs_fs__dag_get_revision() probably needs to be smarter about this
case, though quite how it can tell whether the transaction's been changed
yet, I'm not sure.
I guess the difference between the two approaches is that BDB treats a
transaction initially as an unaltered copy of the base revision's root,
while FSFS treats it as a new node from the start (which it always will
be, of course).
Whatever we do, I think that we need to document the requirement that
svn_fs_node_created_rev() return the base revision on an unmodified
transaction, since that's what we're relying on. That can be a separate
patch, though. Err, no, wait ...
... come to think of it, won't the following scenario still be possible
(in either FSFS or BDB): create a transaction based on r0 [with r1 as
HEAD], add a file to the transaction, modifying the transaction root and
making _created_rev() return SVN_INVALID_REVNUM, _then_ propset the root
(which is out of date)?
Rambling over,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 12 14:04:22 2006