RE: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely r evis ion based storage for Zope ?)
Shane, Thanks for the extra tips, I'll check out those interfaces! I'm also getting up to speed on the whole mapper concept, where the work regarding properties handling seems to be ? I've done some reading, and I need to do some more, but I'll get there :) As for the seperation of code ... I now have a "subversion" directory as a sibbling to "fs" ... I had to edit a couple of files outside that directory, but still the seperation is nicer. eventually I'd have to make it into a product, is that doable ? J.F. -----Original Message----- From: Shane Hathaway To: Jean-Francois.Doyon@CCRS.NRCan.gc.ca Cc: zope-dev@zope.org Sent: 13/04/2004 11:43 AM Subject: Re: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely revis ion based storage for Zope ?) On Mon, 12 Apr 2004 Jean-Francois.Doyon@CCRS.NRCan.gc.ca wrote:
This is step one because, as Shawn suggested (Thanks for the pointer, that's what I needed!), this simply means that Zope uses SVN purely as a filesystem.
Because of subversion's nature, I want to look at 2 things beyond this that traditional filesystems don't support:
To take this to the next level, you need to implement IFSReader and IFSWriter instead of the more basic file operations interface. See Ape/lib/apelib/fs/interfaces.py. In IFSReader/IFSWriter, you're a little closer to objects, and you work with OIDs instead of paths. I expect that history and version support will require us to augment IFSReader or add another interface.
- Use zope's username for SVN logging. - History/Undo support: View past revisions of an object, and revert to such a past revision. - Zope Version support: SVN is fully transactional and atomic, this should allow for support of Zope versions (I think ?)
These seem doable.
In the longer term, there's great opportunity for:
- "Built-in" conflict management and resolution: No more need for a "SafetyBelt" type approach. Right now I haven't looked at this at all. I plan to implement smart merging where possible (It might work already actually, I just need to test it). True conflicts (Where a merge can't be accomplished withouth user interaction) would raise some sort of conflict error.
This could be complicated, because after the merge you have to be sure Zope caches the merged state rather than either of the intermediate states. The idea has potential, though!
- Editing Zope content objects through interaction with the svn repository. I can checkout the repository, edit some objects, and chek them back in, never interacting with Zope directly ... I've already tried this ! Works great for text based content types such as PageTemplates or DTML Documents and so on ... I even did it with a JPG, though because the properties hold width and height, you get some weird looking pictures :) The concept is valid though. There may someday be a way to leverage this functionality better with a purpose built client of some sort.
Sounds neat. Fortunately, Ape doesn't have to be aware of this. :-)
- Leveraging SVN's property management. Content in SVN has properties, much like Zope does. I haven't looked at it yet, but I've noticed ".properties" file appearing ... I'm guessing those are the Zope properties, which would be better handled by subversion's property mechanism. And properties are versioned too !
I think you'll find this easy to do once you implement IFSReader/IFSWriter.
In the realm of the wishful thinking, there's even more:
Right now, HEAD (Latest/youngest revision) is always used and worked with. The really powerful feature I want to eventually get to is publsihing something of a given revision, while editing another. One potential paradigm for distiguishing between the two modes of operation could be to use anonymous vs. authenticated. This is not useful to everyone, but can be in certain circumstances, most notably where authenticated = authors/developpers and anonymous = normal users. This however requires ZMI interfaces, and in my case CMF ones as well ... This would be global though ... Eventually it'd be nice to have per object control of this stuff. Andy McKay says it can't be done, anybody care to contradict him ? :P I image I'd have to monkey pathc something DEEP in the Zope code base, but I find the mix-in class that's the commonn denominator ... why not ?
Well, CMFStaging is designed to address this need. To do this at the database level, you could use versions.
Right now I've been working within the "fs" module of apelib. I'm going to split it off into a seperate one so that it's a clean merge with Ape's code base, in case someone wants to try it, or it eventually makes into Ape's default distribution ?? ;)
You can add a new module, perhaps 'svnops.py', to the 'fs' package. Then we should make the choice between fileops and svnops configurable. Shane
On Tue, 13 Apr 2004 Jean-Francois.Doyon@CCRS.NRCan.gc.ca wrote:
Thanks for the extra tips, I'll check out those interfaces! I'm also getting up to speed on the whole mapper concept, where the work regarding properties handling seems to be ?
Ape supports both annotations and Zope properties. Annotations are blocks of multi-line text, while Zope properties are less constrained. On the filesystem, Ape stores many Zope properties together in a single annotation called "properties". Other annotations include object classification, the remainder pickle (encoded in base 64), and security information. What are the expectations and limits of Subversion properties? If they are blocks of multi-line text, you can store the annotations as Subversion properties. If not, we'll still need a .properties file. (Note that the name ".properties" is thus confusing. Oops.)
As for the seperation of code ... I now have a "subversion" directory as a sibbling to "fs" ... I had to edit a couple of files outside that directory, but still the seperation is nicer.
eventually I'd have to make it into a product, is that doable ?
Why not add your code to Ape? I think it would be easier for both of us to maintain that way. Shane
On Tue, 2004-04-13 at 22:46, Shane Hathaway wrote:
On Tue, 13 Apr 2004 Jean-Francois.Doyon@CCRS.NRCan.gc.ca wrote:
Thanks for the extra tips, I'll check out those interfaces! I'm also getting up to speed on the whole mapper concept, where the work regarding properties handling seems to be ?
Ape supports both annotations and Zope properties. Annotations are blocks of multi-line text, while Zope properties are less constrained. On the filesystem, Ape stores many Zope properties together in a single annotation called "properties". Other annotations include object classification, the remainder pickle (encoded in base 64), and security information.
What are the expectations and limits of Subversion properties? If they are blocks of multi-line text, you can store the annotations as Subversion properties. If not, we'll still need a .properties file. (Note that the name ".properties" is thus confusing. Oops.)
svn supports aribtrary property values. ie you can store binary (remainder pickles, object classification, etc.) of arbitrary size on them. there is some question of how well some naive gui client will do when trying to list such properties, as there is currently no notion of metaproperties/property schema beyond the property namespace for introspection of a property. -kapil
participants (3)
-
Jean-Francois.Doyon＠CCRS.NRCan.gc.ca -
Kapil Thangavelu -
Shane Hathaway