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

[Jean-Francois.Doyon at CCRS.NRCan.gc.ca]

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 at CCRS.NRCan.gc.ca
Cc: zope-dev at 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 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