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

[Kapil Thangavelu]

On Wed, 2004-04-14 at 19:14, Shane Hathaway wrote:
> On Wed, 14 Apr 2004 Jean-Francois.Doyon at CCRS.NRCan.gc.ca wrote:
> 
> > My initial, uneducated thoughts on the topic were simplistic, but then I'm a
> > big K.I.S.S. fan: simply pickle the entire object back and forth as one
> > entity.  This means for each object, there is one file on the fs.  The
> > benefit is greater simplicity ... the downside is that you couldn't check
> > those files out of subversion and interact with them.  I also have to
> > imagine the former is faster ?
> 
> If you store pickles, you can't merge, you can't store properties, in fact
> you can't even store folders as directories or keep track of references
> between objects.  At that point, you'd do much better to just use
> FileStorage--KISS, after all.  Ape's real utility is in breaking objects
> apart for storage.  If you don't need that, you don't need Ape.  But I
> like to think it makes the job of breaking objects apart for storage
> relatively simple.
> 
> > But if usnig the latter, then I'd think that in SVN there would be only 1
> > file, written by a specific mapper for a specific content type, say image.
> > the data written to the file is such that if checked out, the file "works",
> > so I can open it in photoshop or something.
> > 
> > I however, would simply put everything else in properties, if that makes
> > sense at all. Zope properties, security information, and so on.  1 porperty,
> > 1 piece of data. No need for reading/writing multi-line text.
> 
> That's fine, although you'll need to distinguish Zope properties from 
> other kinds of properties.  For example, if some object has a class_name 
> Zope property, you'd be in trouble if the system mixed that up with the 
> class_name key of the object classification.

i don't think needs to much worrying about, just prefix zope properties
with 'zope:' much the same way svn does with its properties
'svn:externals'

> 
> > The only thing I'm not so sure about is this "remainder" ... Though if it
> > really is a base64 encoded string, there's no reason not to put that in a
> > property as well.
> 
> That's correct, it's always base64 encoded (with some comments.)
> 
> > The benefits I see:
> > 
> > - The filesystem reflects the object structure, no extra files lying around.
> 
> Definitely.
> 
> > - a more consistent way to setup mappers/gateways: there's "data", and
> > there's everything else. Have a common/defined/smart way of handling
> > "everything else".
> 
> I would recommend you defer this for a while.  Lots objects don't
> easily fit this model.  For example, what is the "data" of a CMF tool?  
> We can make plenty of progress on Subversion without thinking about 
> changing the way mappers are defined.
> 
> > - with the use of the properties related svn funtions, we better leverage
> > SVN's features.
> 
> Yup.
> 

another thing to keep in mind here, svn is basically a versioned fs, and
in addition to node/content history tracking and it has
facilities/functions for apply deltas to content, and recieving delta
diffs back etc, but these apply to node/content bodies and not to
properties. ie. there are no facilties for diffing properties, and this
would need to be implemented in python.

-kapil