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:

I'm hoping to "get some time" soon to address some of these things.
In the mean time... it's probably worth a look.


>>>>> "GG" == Gerald Gutierrez <[EMAIL PROTECTED]> 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.

Zope maillist  -  [EMAIL PROTECTED]
**   No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to