On Thu, 2002-08-01 at 22:13, Shane Hathaway wrote:
On 1 Aug 2002, Gary Poster wrote:
Hi Shane. I've been thinking about Zope versioning, and I also did a bit of list searches for past discussions on this general topic. One problem that seems pertinent to really any external-to-zope versioning system, including Subversion, is dealing with non-folder object managers. If you want to manage the contents of these special object managers individually in your versioning system, you're running into some trouble, some parts of which seem insurmountable to me at the moment (from my admittedly limited knowledge ;-).
It's really only a theoretical problem. To store the extra data about folderish objects, you can save the data in a hidden file called, for example, ".properties". The theoretical problem is that someone might give an object that name, since it's perfectly legal. In practice, you can just prevent people from creating Zope objects with a name that starts with a dot. 99% of the users won't mind at all, and those that do can use two dots instead. :-)
Yes, the more serious problem in my mind stems from something that might be a misunderstanding of mine. Given a hypothetical folder-like instance called "myFLI", we would presumably want, in CVS (or Subversion, or whatever) a folder named "myFLI" containing the children and a file named, to borrow your example, "myFLI.properties.zexp" that *only* contains the non-ObjectManager-children properties, whatever they are. But, as I understand it, when you pickle an object for storage as a zexp--in the way the ZCVSFolder does it, for instance--you are pickling the object *and* its (ObjectManager) children: not what we want. This is the bigger stumbling block for me. Is this fixable? Overriding __getstate__ (I assume?) just for this seems fragile (can we guarantee the source of the ObjectManager children in the object, for instance? I don't think so). So that was my concern.
I find myself agreeing with earlier posters (earlier as in 2001--Paul, for one, I think) who said that Zope itself might need to support full versioning, a la DeltaV or somesuch, itself. This makes sense to me, but I didn't find any historical documents on zope.org as to progress or as to reasons for abandonment of this approach.
I've thought a lot about Zope object versioning, and I can't see any reason that Zope can't use an external repository. It would help a lot to work with a repository that is transactional and can version directories--but guess what, that's exactly what Subversion is good at!
:-) Yes, subversion seems cool.
What's the deal? Would this be a huge effort, or is it definitively problematic for a reason I don't see, or is it stalled for some other reason?
It's only stalled because we're all busy working on other cool stuff. :-)
The best possible reason. Thanks Gary