[Zope-CMF] Revisions & CMF

[seb bacon]

* Shane Hathaway <shane@digicool.com> [010530 16:12]:
> 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.

Yes, but the reason FileStorage grows so much is because it is
undoable, and this fact alone necessitates a pack facility.  Packing
and Undoing are mutually dependent, even though one is an
implementation detail, and the other a requirements detail.  I've only
ever used FileStorage, but I presume the 'Undo' tab is in the
interface even in a non-Undoable Storage?  Here, then, there's no clean
separation of implementation and requirements definition.

In the same way, I think the decision to store multiple copies of an
object necessarily implies the need to provide packing facilities in
the implementation.  In turn, this implies the need for a property on
a version which indicates whether or not it can be packed, and perhaps
more significantly the ability to set this property from a WorkFlow.
 
> 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.

Right, but I'd argue (on the basis of what I just said) that the
strategy should expose a packable property which can play with
Workflows, since this is likely to be a problem for any
implementation.  Or perhaps I'm inexplicably hung up about a very
minor issue ;-)

cheers,

seb