In it's current released form ZCVSMixin really does help with a lot of the configuration/process problems in developing with Zope. You can still 'grep' for stuff, and it is possible to perform simple edits in the xml representation without much fear of actually breaking anything (it's pretty obvious where the text of a method is stored etc.. ). However I have not really found this necessary. We use ZCVSMixin all the time, and (almost) never touch the filesystem directly. 1) Each developer works in their own Zope, with their own local 'checkout' of the project (many projects involve both instantiated Zope objects, and Python Product source code, all of which are managed in CVS). 2) When you are 'editing' a Zope object you use an editor that knows about FTP (e.g., emacs), WebDAV or a web browser. 3) You can use the 'normal' CVS process (update, modify, checkin). 4) You can still do sensible 'diffs' on the xml representation and get a pretty good idea about what's happening. 5) It's easy to set up a 'test' Zope, and a 'live' Zope each of which also has access to CVS. Periodically we update the 'test' Zope and let users bang away at it looking for bugs. When we're ready for an update to the live server we checkin our code tag it... (you can still use the filesystem CVS commands to tag versions recursively!) and then update the live server (inside a Zope Version) to that tag. When we save the Zope version we are fully updated. You still need to 'know too much' to use this process effectively, but, it is a pretty workable process, especially for a site that is constantly evolving (are there sites out there that *don't* constantly evolve?) It has also turned out that we occasionally need to make a *really* simple change on the live server... (there is no way this could possibly break anything... so I'll just change it!). As silly as that sounds.. it happens. It's nice to know that we can simply check that change in.. and know that all the developers will get it.. even though they are working on different systems. There are still a few annoying bugs, and there are several major issues that need to be addressed: http://dev.zope.org/Wikis/DevSite/Proposals/SynchronizationMechanismZCVSMixi... I'm hoping to "get some time" soon to address some of these things. In the mean time... it's probably worth a look. -steve
"GG" == Gerald Gutierrez <pozix@home.com> writes:
GG> At 02:37 PM 1/18/2001 -0600, you wrote: >> do an xml export. You can save cvs that to your hearts content. GG> ... but then I'll have to forego readability, edit-ability, GG> etc. GG> Frankly, I'm a little surprised that this isn't a problem for GG> more people, given the drawbacks of having to give up many of GG> the existing tools, having the application server only be able GG> to export in a proprietary format, and being bound to the GG> application server for so many development-related tasks. It's GG> impossible to do a simple grep through the code, for example GG> ... GG> I'm trying to reconcile this, as you might see, because I want GG> to use Zope but am having a hard time making it work for me. GG> Gerald.