Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)

[Jean-Francois.Doyon at CCRS.NRCan.gc.ca]

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: zope-dev-bounces at zope.org [mailto:zope-dev-bounces at zope.org]On
Behalf Of Kapil Thangavelu
Sent: April 14, 2004 6:59 AM
To: Shane Hathaway
Cc: Jean-Francois.Doyon at ccrs.nrcan.gc.ca; zope-dev at zope.org
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  -  Zope-Dev at zope.org
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 )