On Tue, Dec 13, 2005 at 05:16:01PM -0500, Greg Hudson wrote:
> On Tue, 2005-12-13 at 20:32 +0000, Malcolm Rowe wrote:
> > No, because I'd like to create or open the file in the implementations of
> > svn_fs_create_txn2() and svn_fs_open_txn(), which create transactions,
> > not transaction roots.
>
> Why do you want to do it there?
>
Partly because that's where the file is opened at the moment, and partly
because it seemed to make sense:
Open/create transaction: open the file
Perform work against the transaction's root: write to the file
Close/commit/abort transaction: close the file
However ...
> If the goal is to ensure that multiple roots for a single transaction
> use the same file, you may have to cache the file handle in the svn_fs_t
> object, since a caller could be using different handles to the same
> transaction.
(Yes, that's the goal - also that we can't get into the situation where
we've unwritten buffered data in one apr_file_t, then append to the
written data in another apr_file_t).
It had completely escaped my notice that a caller could open the same
transaction more than once, so you're quite right: stashing something
in the transaction won't work.
So it sounds like we'd need some kind of transaction-id-keyed stash
in the svn_fs_t object - it would also need to be reference-counted
(by number of active svn_fs_txn_t objects), so that we would know when
to close the files for a particular transaction, yes?
However, doesn't this apply to the filesystem as well? Is there any
reason that the caller couldn't open the filesystem twice, create a
transaction through one svn_fs_t, and reopen it (by name) via another?
Wouldn't we need a global cache?
> If we're going
> to change the FS model, I think we want to look into getting rid of
> transactions as an object type, not intertwining them better with roots.
> (Although that would require revving some APIs.)
>
Sounds interesting, if tangential - what kind of thing are you thinking
about?
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 14 12:15:21 2005