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

[Andrew Lahser]

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 )