[Zope-dev] Re: [Zope] using CVS for Zope object stores?

[Stuart 'Zen' Bishop]

[Redirected to zope-dev]

On 13 Dec 1999, Guido A.J. Stevens wrote:

> In short, we crave for a way to use cvs on Zope object stores. 

I've thought of two ways of doing this 'seemlessly', both involving
writing a new Storage module for Zope.

    FSStorage -
	Store each non folderish object in an individual file in ascii
	pickle format
	For each folderish object, a directory is created and the actual
	ascii pickle data is stored in a 'magic' file in this directory.

	Caveats:
	    If you use 'id' as the filename, ids will be restricted
	    to those available on the underlying OS (including case issues),
	    and there would need to be reserved id's (eg CVS, RCS, '__magic__').
	    Alternatives will give meaningless names (eg using a ascii
	    representation of _p_oi).
	    Undo would probably not be available

	Bonuses:
	    May outperform existing FileStorage on certain hardware (eg. my 
	    NetApp 740)
	    Allows integration with tools like CVS or RCS, although I have
	    no idea if rollback could be done on individual objects.

    CVSStorage - 
	As FSStorage, but store objects directly in a CVS repositary.

	Caveats:
	    Speed. A fork tax would be required each time an object is
	    read (to call the OS's cvs executable), unless someone wraps
	    the CVS source into cvs.py (Might be easy with SWIG - I have no
	    idea). Even without the fork tax, it will be slower accessing
	    the object through CVS. And large memory caches don't help
	    for writing objects...

	Bonuses:
	    Point in time rollback
	    Possible to add hooks to allow viewing of previous revisions
	    of documents into Zope, perfect for Document Management
	    products.
	    Not only undo, but in theory it would be possible to support 
	    branching and merging if Zope became intelligent enough
	    (loosly distributed databases anyone?)

It might be worth using some variant of pickle that is more CVS
friendly (ie. more linefeeds).

> Has anybody been working on this? Has anybody come up with a more
> intelligent approach than diffing and patching wholesale xml exports?
> Do we need to wait for a different (non-monolithic) filestorage
> backend - is anybody working on /that/?

It doesn't exist yet, and I have plenty of other stuff to keep me busy
at the moment....

-- 
 ___
   //     Zen (alias Stuart Bishop)     Work: zen@cs.rmit.edu.au
  // E N  Senior Systems Alchemist      Play: zen@shangri-la.dropbear.id.au
 //__     Computer Science, RMIT 	 WWW: http://www.cs.rmit.edu.au/~zen