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: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
