[Zope3-dev] DISCUSS: Zope3 and Zope2's version object

[Paul Everitt]

The "Version" object I'm referring to is a high-level Zope object that 
hooks the long-running transaction support.  Not the multiple revision 
nature of the ZODB.

To recap what it does and why there's a problem, you create a Version 
object that gives you a UI for joining and leaving a Version.  The 
changes that you make aren't visible to people outside the Version. 
When you're done, you commit the changes in the Version, thus committing 
the long-running transaction.

This is extremely powerful and cool.  Unfortunately, we never use them 
on any sites involving more than one author because of locking. 
Anything that you change is locked until you commit the transaction, 
which might be weeks or never.  The locks extend to things like the 
folder you added something to (nobody else can modify the folder after 
that) and even worse, parts of the catalog.

Further issues are cosmetic.  For instance, there isn't a good interface 
for finding all things locked in a version.

Work could be done to alleviate some of these problems, but probably not 
to eliminate it.  And with proper versioning (with a repository, etc.) 
coming...

--Paul

Guido van Rossum wrote:
>>With that in mind, should we consider the current Version object to be 
>>something that will *not* make it into Zope3?  I'm against it going in 
>>with the drawbacks that it currently has.
>>
> 
> Support for versions in ZODB (e.g. FileStorage) is quite deep and
> complex.  It will be hard to rip it out without damaging other parts.
> OTOH, I'd be happy if it was carefully left out from ZODB4, if and
> when that ever gets started.
> 
> --Guido van Rossum (home page: http://www.python.org/~guido/)
>