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 ?
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,
> what I needed!), this simply means that Zope uses SVN purely as a
> Because of subversion's nature, I want to look at 2 things beyond this
> 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
closer to objects, and you work with OIDs instead of paths. I expect
history and version support will require us to augment IFSReader or add
> - Use zope's username for SVN logging.
> - History/Undo support: View past revisions of an object, and revert
> a past revision.
> - Zope Version support: SVN is fully transactional and atomic, this
> 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
> plan to implement smart merging where possible (It might work already
> actually, I just need to test it). True conflicts (Where a merge
> accomplished withouth user interaction) would raise some sort of
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
> I can checkout the repository, edit some objects, and chek them back
> never interacting with Zope directly ... I've already tried this !
> great for text based content types such as PageTemplates or DTML
> and so on ... I even did it with a JPG, though because the properties
> width and height, you get some weird looking pictures :) The concept
> valid though. There may someday be a way to leverage this
> 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
> like Zope does. I haven't looked at it yet, but I've noticed
> file appearing ... I'm guessing those are the Zope properties, which
> be better handled by subversion's property mechanism. And properties
> versioned too !
I think you'll find this easy to do once you implement
> In the realm of the wishful thinking, there's even more:
> Right now, HEAD (Latest/youngest revision) is always used and worked
> 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
> use anonymous vs. authenticated. This is not useful to everyone, but
> in certain circumstances, most notably where authenticated =
> authors/developpers and anonymous = normal users. This however
> interfaces, and in my case CMF ones as well ... This would be global
> ... Eventually it'd be nice to have per object control of this stuff.
> McKay says it can't be done, anybody care to contradict him ? :P I
> have to monkey pathc something DEEP in the Zope code base, but I find
> 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
> split it off into a seperate one so that it's a clean merge with Ape's
> base, in case someone wants to try it, or it eventually makes into
> default distribution ?? ;)
You can add a new module, perhaps 'svnops.py', to the 'fs' package.
we should make the choice between fileops and svnops configurable.
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -