[Zope] Versions problem in 2.6.1

[Chris Kratz]

Hello Wil and Tom,

We had the exact same problems with versions after we moved to 2.5.1.  Up to 
that point we had used them pretty extensively.  The symptoms were that after 
a period of time, saving a version didn't always commit all items.  The 
control panel showed no open versions, but the items were locked nonetheless.  
Also packing caused poskey errors as was also noted in the previous email(s).

We learned that if the version had been deleted, we could recreate the version 
in the same location with the same name.  Then we had to manually find all 
the unsaved objects  and resave them within the version. Some objects we 
actually had to modify (I think scripts were this way, but adding or removing 
an empty line was good enough).  Anyway, then we could commit the version.  
Sometimes this was an iterative process (save, check for locked objects, open 
version, save, check... etc).

This eventually forced us out of using versions due to the frustration of our 
developers having to keep notes on all the modified objects so we could go 
check them after a version was committed.  We had enough problems with 
commiting partial versions on our live site that we decided we had to use 
something that worked better.  They were a wonderfull tool when they worked, 
but it appears to me that they have been broken for several versions now of 
zope.  I think that the reason you haven't found much on the list is that 
many people don't use versions in a day to day way.  The one situation where 
they did seem to work consistently was when you were making very small 
incremental changes to one or more objects and the changes were cut in almost 
immediately.

After some work, we are now using a combination of cvs with each developer 
having their own copy of zope and a home grown python script that walks the 
db and dumps every object to the filesystem.  Then we use zsyncher to move 
objects around and keep things in sync between the zope instances.  CVS gives 
us a persistent versioned "backup" while keeping the objects in the standard 
zope data.fs for normal serving.  When a developer is ready to start a new 
project, they pull a copy of the data.fs from our dev server and start 
working.  CVS provides lists of objects that need to be updated from dev on a 
dailly basis.  Our setup isn't elegant, but it has worked for us.  I would 
suggest that unless you can find a solution to the issues with zope 
versioning that you may want to try another tact for keeping versions of your 
code/website.  

I have been watching with interest some of the other projects that have been 
evolving (directory storage, etc) to allow tighter integration with zope and 
file system based utilties such as cvs.  Perhaps one of those projects might 
be a good place to start looking if you think you may want to move in that 
direction.

Anyway, that was our experience.  Good luck,

-Chris

On Monday 17 February 2003 03:24 am, Wil Cooley wrote:
> FWIW, I just spent the last few hours fighting with the same thing.
> Another thing I'm noticing is that even when I do save the version, the
> changes aren't publicly accessible.

-- 
Chris Kratz
Systems Analyst/Programmer
VistaShare LLC
www.vistashare.com