[Zope-dev] Zope components and revision control with cvs

Gary Poster gary@modernsongs.com
01 Aug 2002 22:58:26 -0400


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