Kapil, Right now, the svn transactions are entirely contained within a single fileops operation: for example a "mkdir" connects to a transaction root, performs the necessary operations, and commits, all in one shot.
Last night I took some more time to try and learn more about Ape's functionning (Where events come from, which interfaces are used for what, and TPC), so I'm starting to understand more ... The more I learn, the more I think closer integration between SVN txn's and Ape's TPC would be a good place to start before looking at adding features like history support and so on: defining a model for what happens in svn for each TPC related call (connect, vote, finish), and then as Shane had said, look at IFSReader/IFSWriter (Which I now call ISubversionReader/ISubversionWriter :P) to match. Right now the fs implementation stores "script commands" that are cummulated upon connect() (I think?), validated as best as possible upon vote() and run upon finish(). I don't see why this couldn't be adapted to SVN txn's ... connect() = start a txn, vote() = validation (what this entails needs to be defined, could involve delta operations, revision number matching, etc ... ?), finish() = commit the svn txn. Because we're within an svn transaction, there would be no need for fs style script command accumulation however, which is nice. J.F. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Kapil Thangavelu Sent: April 14, 2004 6:59 AM To: Shane Hathaway Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely revis ion based storage for Zope ?) On Tue, 2004-04-13 at 12:01, Shane Hathaway wrote: > On Tue, 13 Apr 2004, Kapil Thangavelu wrote: > > > since > > objects modified in a version are in essence locked from participating > > in other transactions, actions like modifying content in a version in a > > cmf site amounts to locking the catalog from changes outside of the > > version, which amounts to shutting down write activities to a cmf site. > > This is only true of FileStorage. Some other storage could implement ZODB > versions with merging capability rather than locking. > good point, just because hasn't been doesn't mean it can't ;-) although i wonder if there is some hand waving in progress here that i can't see. i guess my semantic notion of versions has been that of long lived transactions, and is there a better means of thinking of them? how do they play across with multiple mounted zodbs? what would something like merge mean in the context of a catalog? > > i'm also curious how you dealt with svn transactions as part of the ape > > integration work to date. > > The same way it tries to impose transactions on the filesystem: in the > vote phase, Ape looks for possible problems and aborts early if it detects > anything that will cause the transaction to fail. Obviously, this > provides no guarantee, but covers many cases. > i was more curious how jean-francois was doing the svn ops in fileops, as svn is fundamentally a transactional store (as opposed to the fs), ie is there some record boundary notion of ape signalling the end of serialization for an object set, or was each operation being conducted in a separate svn transaction. -kapil _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )