[Zope] RE: [Zope-dev] Re: source control

[Jay, Dylan]

> -----Original Message-----
> From: Rob Page [mailto:rob.page@digicool.com]
> Sent: Friday, September 24, 1999 09:26
> To: 'Andrew M. Kuchling'
> Cc: 'zope@zope.org'
> Subject: [Zope] RE: [Zope-dev] Re: source control
> 
> 
> > What should Zope source code control look like?  The ZODB's 
> versioning
> > is too fine-grained, because every little change is stored as a
> > separate version.  What you really want is to draw a circle around a
> > given set of DTML + SQL queries + other objects, and store them as a
> > snapshot.  (ExternalMethods are tricky, because they're in source
> > files outside the ZODB.)  
> > 
> > Vague speculation, at least for CVS support: imagine having a 'CVS
> > checkin' tab on a folder.  Clicking it would loop over the 
> contents of
> > the folder, exporting each object in the XML format and 
> writing it to
> > some preconfigured CVS working directory.  After writing 
> the files, a
> > standard 'cvs commit' is done.  That's terribly crude, and running
> > 'cvs diff' will require reading XML to interpret the 
> changes, but it's
> > a start.  
> 
> Ooooh..  I think these two paragraphs are a neat idea.  Maybe 
> instead of
> a folder what if you had a drop-in object called a CVS_Container.  The
> CVS_Container would contain the IDs of some number of Zope objects.
> Visiting the CVS_Container would let you add/edit/delete 
> elements in the
> Container and/or check-in/out/update.  I think a folder would often be
> too "large" to correlate nicely into CVS.
> 
> Thoughts?  

I think my idea of a mixing the two ideas of Zope Versions and external
source control has merit. A Version already encapsulates a whole group of
changes. It does this simply with all that is required is to join the
Version and it collects all the changes after that. Then a save performs the
above operation of adding the changed objects to a snapshot on disk and a
cvs commit is run. This would require serialization of commits but that
isn't hard to do.