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 ?


-----Original Message-----
From: Shane Hathaway
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
> filesystem.
> 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/  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
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
> 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
> 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
> 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
properties, much
> 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
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
> ... 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
image I'd
> 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
going to
> 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 '', 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 - )

Reply via email to