On 9/12/06, Malcolm Rowe <malcolm-svn-dev@farside.org.uk> wrote:
> 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).
Well, to some degree that seems to be conflating the concepts of "fs
root" and "node of the root directory". Like, it seems to me that a
"transaction root" is a different object than the "revision root" it
was created from, but the root directory node of the repository under
the transaction root should be the same object as the root directory
node of the repository under the revision root until it is modified.
> ... 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)?
I need to look into that more. I suspect the answer is that it works
fine because svn_client_commit calls change_dir_prop before opening
the subdirs instead of after, but I haven't checked that, and that
just means that the particular use in svn_client_commit happens to
work, not that the logic in libsvn_repos is sane.
--dave
--
David Glasser | glasser_at_mit.edu | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 12 17:54:27 2006