I am seeing a problem in Zope 2.6.1, freebsd4, Python 2.1.3 (with thread patch) when using versions. I have modified objects that ZMI thinks are locked (they show the red-diamond when I'm working in the version, and the red-diamon / padlock when I'm not), even though I saved those changes, with a comment, from the Version management panel. Indeed, I cannot save the changes from the Version ZMI: it says there are no unsaved versions. Yet Zope thinks there are unsaved versions, as witnessed by the presence of the lock icon when I working in the version. The Version undo panel shows my saved versions! Evidently there is a disconnect here somewhere. The my folder structure is: /foo /bar Version Object /baz files with changes Anyone have any suggestions? I would prefer not to undo the changes. On a related question: can I work in a version without going through the ZMI? In other words, if I want a to test the changes as if I were coming in live from the outside, is that possible? Or must I go through the ZMI and run the site from there? TIA. -tree -- Tom Emerson Basis Technology Corp. Software Architect http://www.basistech.com "Beware the lollipop of mediocrity: lick it once and you suck forever"
Tom Emerson wrote at 2003-2-14 09:10 -0500:
I am seeing a problem in Zope 2.6.1, freebsd4, Python 2.1.3 (with thread patch) when using versions. I have modified objects that ZMI thinks are locked (they show the red-diamond when I'm working in the version, and the red-diamon / padlock when I'm not), even though I saved those changes, with a comment, from the Version management panel. Indeed, I cannot save the changes from the Version ZMI: it says there are no unsaved versions. Yet Zope thinks there are unsaved versions, as witnessed by the presence of the lock icon when I working in the version. The Version undo panel shows my saved versions! Evidently there is a disconnect here somewhere. I have seen thinks like this, too.
It happens when your browser sends the version cookie (its called something like "ZopeVersion"). Ensure, no cookies of similar name are send to Zope and see whether the problem disappears. The "version management" in "Control_Panel" is a reliable source of information about versions and how to save/quit them. Dieter
Dieter Maurer writes:
Tom Emerson wrote at 2003-2-14 09:10 -0500: [snip] I have seen thinks like this, too.
It happens when your browser sends the version cookie (its called something like "ZopeVersion"). Ensure, no cookies of similar name are send to Zope and see whether the problem disappears.
No cookies of any type from the server in my browser. I even tried from a completely different machine. Nothing.
The "version management" in "Control_Panel" is a reliable source of information about versions and how to save/quit them.
The control panel claims that there are no non-empty versions, which is obviously false since the lock icons are visible. -tree -- Tom Emerson Basis Technology Corp. Software Architect http://www.basistech.com "Beware the lollipop of mediocrity: lick it once and you suck forever"
On Fri, 2003-02-14 at 12:10, Tom Emerson wrote:
Dieter Maurer writes:
Tom Emerson wrote at 2003-2-14 09:10 -0500: [snip] I have seen thinks like this, too.
It happens when your browser sends the version cookie (its called something like "ZopeVersion"). Ensure, no cookies of similar name are send to Zope and see whether the problem disappears.
No cookies of any type from the server in my browser. I even tried from a completely different machine. Nothing.
The "version management" in "Control_Panel" is a reliable source of information about versions and how to save/quit them.
The control panel claims that there are no non-empty versions, which is obviously false since the lock icons are visible.
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. I'm using RH 7.3, installed from the binary x86-linux package for 2.6.0 with the upgrade tarball to 2.6.1 applied over it. I've seen a few other odd things tonight that are probably related, like after packing 0 days the folder with my site gave me POSKeyErrors, which from looking at the source, indicated major badness. Fortunately, I had exported it shortly before, so I mv'd my Data.fs* out of the way, started Zope, and imported my site back. I couldn't find anything in Collector, and I don't really know enough to be sure I'm not doing something stupid. FWIW, the Versioned files I initially had trouble with were probably put into the version around 2.5.1, remained in the version through the 2.6.0 and .1. But now I'm seeing it again with files that only were created today under 2.6.1. I'm guessing I'll downgrade until I can figure it out. Yes, you can get to your version just by appending '?Zope-Version=/path/to/version' to the URL. Hmm... I notice now the versions refer to a version object in a different place than the site is at now. I created a Version in the original path, started working in it, opened and saved my locked files, then committed them and everything seems fine. I'm going to delete the version object and create a new one... Wil -- Wil Cooley wcooley@nakedape.cc Naked Ape Consulting http://nakedape.cc * * * * Linux, UNIX, Networking and Security Solutions * * * * QCSNet http://www.qcsn.com * * * * T1, Frame Relay, DSL, Dial-up, and Web Hosting * * * *
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
participants (4)
-
Chris Kratz -
Dieter Maurer -
Tom Emerson -
Wil Cooley