[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] Change svn_fs_root_t to include pointer to related txn

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2005-12-14 19:44:29 CET

On Wed, 2005-12-14 at 11:14 +0000, Malcolm Rowe wrote:
> 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?

There's no particular reason, no, but it seems unlikely that a caller
would do that without a pool cleanup in between. (Perhaps my
transaction argument is overblown for the same reason. Part of my
uneasiness here is that we seem to have a caller *somewhere* who is not
aborting a transaction after receiving an error, and we don't understand
where that caller is and how it works. I'm not sure the right approach
is to work around this behavior in the FSFS code; perhaps the right
answer is to document that you must give up on a transaction after
receiving an error, and hunt down and eradicate any code which isn't
doing so.)

> > 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?

Instead of creating or opening a txn, you'd create or open a txn root.
There's no such thing as a "revision" object in the svn_fs interface, so
I don't see the need for a "transaction" object either.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 14 19:53:29 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.