[Zope-CMF] Revisions & CMF

[Shane Hathaway]

Over the nice long weekend I had fun with my family and occasionally
pondered revisions for CMF.  I've come to a few realizations.

Ken's proposal contained a good description of the motivation for
versioning.  Basically we want the default workflow to allow people to
edit a future version of a document while the current version remains
published.

A lot of the ideas presented are actually more alike than it sounds at
first.  A future version of a document is really the same as a CVS
"branch".  No, we might not need diffs and merges, but we do need the
concepts that are fundamental to CVS.

A Zope "Version" object is also equivalent to a CVS branch.  However,
FileStorage, the default implementation of the ZODB storage layer, is
currently hardwired to disallow concurrent branches.  I don't know
whether BSDDB3 storage makes the same assumption.

A "revision" is different from a branch: every time you change a
document a new revision is stored.

It puzzles me a little that people are concerned about storing multiple
copies of a document.  Did you know that in FileStorage, every time you
change an object a new complete copy is created?  If you had a 10 MB
document and changed it 100 times, your database would grow by 1000 MB. 
Only packing would remove the old copies.  There are certainly ways to
store only one copy, but the CMF probably isn't the place to solve this
problem.

Here is a crude metaphor.  The CMF is a large star with enough mass to
draw in everything near it.  Like any software, as soon as you add
partial support for some new feature, gravity pulls until the rest of
the feature is there.  If you don't want to turn your software into a
red giant or a black hole you have to carefully put in the *right*
things and enforce a certain level of separation from other software
(thus establishing orbit! ;-) )

So what I have in mind is to separate the CMF from the strategy used for
versioning (that is, branching).  A new portal_versions tool will
implement a versioning strategy.  The default implementation might
choose to use Zope versions, create copies of objects, or assume objects
implement versioning internally.

Shane