[Zope-Checkins] Re: SVN: Zope/trunk/ - Applied patch for

Tim Peters tim.peters at gmail.com
Mon Mar 21 00:23:43 EST 2005


[Tim Peters]
...
>| We can't afford to| maintain a separate ZODB just for Zope 2.8, so
view moving
>| to ZODB 3.4| as a requirement for Zope 2.8.

[Tres Seaver]
> Note that the "we can't afford" comment is the primary justification for
> moving to a 'svn:external' style of inclusion.

We couldn't afford it if it were all done with symlink magic in CVS
either.  Different versions of ZODB turn into _very_ different code
bases over time, and ZODB has become overwhelmingly a one-person show.

> On that basis, I am going to argue against the "copy / fork" model we
> are currently using for ZODB:  we *can't* tolerate the maintenance
> burden imposed by the separate copy.

It's an ongoing pain for me for sure.  Note that zdaemon and ZConfig
follow the same model.  For that matter, ZODB 3.4 also stitches in
zope.{testing, interfaces} from Zope3 for its "standalone" releases
too.  None of this is obvious to anyone looking at any of the SVN
checkouts.

> Rather, (so I am arguing) the Zope SVN should point at the "latest
> stable release" (tag, not branch!) of ZODB at the time Zope is released,

Can't work, really -- e.g., often current Zope development needs an
alpha or beta ZODB because of ZODB bugs triggered by Zope, or even
cooperating bugs in both Zope and ZODB (Zope 2.7.2, for example).

> and only have the external link changed *at the time the Zope release is
> being prepared*.

That's a recipe too for last-second integration crises.  Under CVS,
there aren't last-second integration surprises because changes to ZODB
are tested all along with the Zope du jour.

>  If that means that we link in ZODB 3.4 (given that it is ready to go when Zope 2.8
> is), then that will be simple.  If not, then we will have to pick up the version which
> *is* available.

Zope 2.8 final will certainly be released with a released version of
ZODB.  But it's unrealistic to imagine that ZODB releases get
significant real-world testing *apart* from being released with a
Zope.  For Zope 2.7, I wait until Andreas releases a new Zope-final,
and then (same day if possible) package a ZODB release containing what
shipped with that Zope.  This has worked very well, but I pay a lot of
attention to making it work, and am very conservative with ZODB 3.2
changes as a Zope 2.7 release approaches.  Zope3 has gone the same
way; although there have been far fewer Zope3-ish releases, there
haven't been problems with this approach there yet either.

> I will argue likewise for *any* separately-released package (ZConfig,
> Zope3, zdaemon, etc., should all be links to released versions).

I have no actual experience with SVN externals, but I expect they
cause their own problems.  Ppeople working on a Zope most often don't
seem to be aware that some 8 to 11 (depending on Zope flavor) fat
directories full of code don't "belong" to Zope.  As a result, people
routinely check in changes *to* ZODB, zdaemon and ZConfig *from* a
wrong project.  If their changes are to code in a directory stitched
in via an SVN external pointing to an external project's release tag,
then my understanding is that one of two things happen:

1. If they svn commit from the root of their host-project working copy, nothing
   happens -- the changes remain in their local working copy, but
don't end up in
   any repository.  That seems a good way for changes to get plain
lost ("hey, it
   works for me, and I commited the change").

2. If, perhaps in frustration due to noticing that #1 had no effect, they cd to
   the root of the working copy of an external, and svn commit from there, the
   changes *will* commit, and will actually change what's checked in on the
   external's release tag.  Everyone else will "see" the changes then, but the
   external's release tag will no longer contain what was actually released.

If so, "checking in from a wrong project" plain sucks, externals or
not.  If it were possible to mark externals as "read only", that could
help.  Ditto if it were possible to mark a stitched-in copy as
read-only.  Don't know whether either is possible.


More information about the Zope-Checkins mailing list