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

[Kapil Thangavelu]

On Wed, 2004-04-14 at 10:04, Jean-Francois.Doyon at CCRS.NRCan.gc.ca wrote:
> 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.
> 

ok, thats what about what i expected. not ideal but it works.

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

part of the reason i never used ape as a means for svn integration was
was that this imo, mix of high level application operations with zodb
storage level operations never seemed a proper fit as it required
bypassing the storage interface for richer semantic operations. ie i see
reverting a revision, tagging a content tree, or diffing mulitiple
revisions as application operations. still, there have been the some
compelling ideas here about using zodb/ape as an interface.

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

not exactly, you just start a txn, do whatever work, and commit in vote.
see my previous message outlining txn integration difficulties, and why
this is not ideal but currently the best option.

> Because we're within an svn transaction, there would be no need for fs style
> script command accumulation however, which is nice.
> 

sure.

should we move this discussion to an ape specific mailing list?

-kapil