[Zope3-dev] RE: [Zope3-checkins] SVN: Zope3/trunk/src/ Tell subversion to expandthe Id keyword:

[Tim Peters]

> Log message for revision 24749:
> Tell subversion to expand the Id keyword:
>   - replaced old CVS expansion with a clean $Id$
>   - set the svn:keywords property to "Id"

Followed by a megabyte of diffs adding Id expansion to all the .py and .c
and .h files reachable from Zope3.

This included all the files reachable from ZODB and ZConfig.

But, unlike as under the CVS arrangement we just moved from, the SVN
repositories for ZODB, ZConfig and zdaemon have no connection to whatever it
is Jim did to slam *copies* of them into the Zope3 repository:  the changes
to these modules in Zope3 had no effect on "the real" ZODB and ZConfig code,
or on the copies of them in the Zope repository.  Worse, I had already
changed "the real" ZODB code (being very careful at the time *not* to change
the ZConfig and zdaemon code (copies) in the ZODB repository) to do Id
expansion.

So now Zope3 effectively has its own branches of ZODB and ZConfig, and in
the ZODB case a merge with the real ZODB code is going to yield conflicts on
every .py, .c and .h file.

I'd say again that the module-sharing we did under CVS prevented a ton of
needless headaches -- except it doesn't help solve the problem.

Given the way it is, please don't check in changes to ZODB, ZConfig, or
zdaemon code from Zope3 HEAD or Zope HEAD (it still works fine if you're
working under the release branches still under CVS, where the modules are
shared).  I don't think we've established a sane way to get necessary
ZODB/ZConfig/zdaemon changes into Zope or Zope3 HEAD, but implicitly
creating Zope3- and Zope-specific branches of these modules is very easy to
do by accident now.  I can't make time to untangle them without dropping
other work that should be more important than that.