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.
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -