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