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

[Kapil Thangavelu]

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