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

[Shane Hathaway]

On Mon, 12 Apr 2004 Jean-Francois.Doyon at 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