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