Basically, I'm really excited about Zope source control, too! Feel free to delete this post unless you are really interested. ;-) For the past six years, I have worked with a fifteen (or more) year old technology called Uniface. Uniface was unique because it stored its code in just about any database. Sound familiar? Storing code in the database was highly productive, because of a solid GUI IDE, but nearly impossible to effectively version control. In six years of Uniface consulting, I have only come across one client that did effective source control when the code was stored in a database. We exported the code from the database as a platform independant text-based Uniface export file (similiar to, but way before, an XML DTD), and checked this into RCS (this was a few years back, we also had to build our own release management system). To do a rcsdiff, we built a wrapper that converted the XML-like export file into a more human readable format, and passed this along to diff. Our output was human-friendly, but verbose -- you got used to it quick. Finally, because our XML-like export file did not guarantee that the elements would export in the same order each time, we needed this same rcsdiff wrapper to make sure that the source code had _really_ changed before doing a checkin. One really powerful benefit was the ability to version control our "controlled data" in exactly the same manner as the source code. This "controlled data" was essentially setup and default data that was necessary to get the application running after an installation. Another challenge was convincing the IDE to "lock out" developers when someone had a check-out of the object you wanted to edit. The corrollary may be integrating CVS checkins with Zope Versions, because, logically, they are doing the very similiar things. Yet, I can imagine times when one would want to use a Zope Version without a CVS checkin, perhaps, for example, when updating "non-controlled data." For other objects, I could imagine wanting to enforce starting a Zope Version with a CVS checkout. I realize that the issues may be less or more similiar, and I am sorry to be so long winded, but, from my experience, this can be a workable solution. Alas, for large development teams or important projects, solid source control is an absolute requirement. So far, I have maintained my zope sources by export (zexp) and saving these files into a directory structure. I'm considering raising my hand to help. Drew Rob Page wrote:
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?
--Rob
_______________________________________________ Zope maillist - Zope@zope.org http://www.zope.org/mailman/listinfo/zope
(To receive general Zope announcements, see: http://www.zope.org/mailman/listinfo/zope-announce
For developer-specific issues, zope-dev@zope.org - http://www.zope.org/mailman/listinfo/zope-dev )