-----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.