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

[Jim Fulton]

Tim Peters wrote:
>>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.

Right. This is a good thing. The real ZODB, ZConfig and zdaemon projects were
unaffected by Philipp's changes. He didn't need to worry about implicitly
changing a separate project.

 > Worse,

Worse implies that there is a problem to begin with. I don't agree.

 > 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.

I don't think that this is worse at all.

> So now Zope3 effectively has its own branches of ZODB and ZConfig,

It already did.

 > and in
> the ZODB case a merge with the real ZODB code is going to yield conflicts on
> every .py, .c and .h file.

Why would it?  I tried:

   $ svn merge \
         svn+ssh://svn.zope.org/repos/main/ZODB/trunk/src/ZODB \
         svn+ssh://svn.zope.org/repos/main/ZODB/tags/cvs-to-svn-conversion/src/ZODB \
         .
    U zodb4/z4base.py
    U zodb4/z4errors.py
    U zodb4/tests/test_z4utils.py
    U zodb4/tests/__init__.py
    U zodb4/z4utils.py
    U zodb4/__init__.py
   UU zodb4/z4interfaces.py
    U zodb4/main.py
    U zodb4/conversion.py
    U zodb4/z4format.py
    U zodb4/z4iterator.py
    U fsrecover.py
   UU Connection.py
   UU BaseStorage.py
    U __init__.py
   UU winlock.c
    U fsIndex.py
   UU ActivityMonitor.py
   UU config.py
    U UndoLogCompatible.py
    U DemoStorage.py
    U tests/testmvcc.py
    U tests/testZODB.py
    U tests/testSubTransaction.py
    U tests/__init__.py
    U tests/Synchronization.py
    U tests/ReadOnlyStorage.py
   UU tests/sampledm.py
    U tests/test_storage.py
    U tests/Corruption.py
    U tests/testFileStorage.py
    U tests/testConfig.py
    U tests/BasicStorage.py
   UU tests/util.py
    U tests/TransactionalUndoStorage.py
    U tests/LocalStorage.py
    U tests/MinPO.py
    U tests/RecoveryStorage.py
    U tests/testSerialize.py
    U tests/warnhook.py
    U tests/dangle.py
    U tests/testPersistentList.py
    U tests/testConnection.py
    U tests/StorageTestBase.py
    U tests/speed.py
    U tests/testUtils.py
    U tests/testfsIndex.py
    U tests/test_cache.py
    U tests/testCache.py
    U tests/testTimeStamp.py
   UU tests/test_datamanageradapter.py
   UU tests/testActivityMonitor.py
    U tests/MTStorage.py
    U tests/testRecover.py
    U tests/testDemoStorage.py
    U tests/VersionStorage.py
    U tests/testPersistentMapping.py
    U tests/IteratorStorage.py
   UU tests/testBroken.py
    U tests/testMappingStorage.py
    U tests/RevisionStorage.py
    U tests/TransactionalUndoVersionStorage.py
    U tests/testDB.py
    U tests/PersistentStorage.py
    U tests/ConflictResolution.py
    U tests/HistoryStorage.py
    U tests/PackableStorage.py
    U TmpStore.py
    U transact.py
    U MappingStorage.py
   UU interfaces.py
   UU DB.py
    U serialize.py
    U dbmStorage.py
    U fstools.py
    U loglevels.py
    U ZApplication.py
    U utils.py
   UU Mount.py
    U ExportImport.py
    U conversionhack.py
    U FileStorage/format.py
    U FileStorage/fsdump.py
    U FileStorage/__init__.py
    U FileStorage/FileStorage.py
    U FileStorage/fspack.py
   UU broken.py
   UU POSException.py
    U ConflictResolution.py
    U lock_file.py

   $ svn status
   MM     zodb4/z4interfaces.py
   MM     Connection.py
   MM     BaseStorage.py
   MM     winlock.c
   MM     ActivityMonitor.py
   MM     config.py
   MM     tests/sampledm.py
   MM     tests/util.py
   MM     tests/test_datamanageradapter.py
   MM     tests/testActivityMonitor.py
   MM     tests/testBroken.py
   MM     interfaces.py
   MM     DB.py
   MM     Mount.py
   MM     broken.py
   MM     POSException.py

Worked great.

Second, if there are no substantive changes in Zope 3's copy of ZODB, which there
should not be, then we will probably choose to recopy rather than merge.

Note that it's easy to find out that there were no substantive changes:

   $ svn log --stop-on-copy svn://svn.zope.org/repos/main/Zope3/trunk/src/ZODB
   ------------------------------------------------------------------------
   r24749 | philikon | 2004-05-16 09:00:21 -0400 (Sun, 16 May 2004) | 7 lines

   Tell subversion to expand the Id keyword:
     - replaced old CVS expansion with a clean $Id$
     - set the svn:keywords property to "Id"

   When you check-in files in the future and want $Id$ to be expanded,
   make sure it reads "$Id$" in that file; then set svn:keywords to "Id".

   ------------------------------------------------------------------------
   r24582 | philikon | 2004-05-12 04:56:10 -0400 (Wed, 12 May 2004) | 3 lines

   Ignore files/directories that are result of a build process, such
   as .so files.

   ------------------------------------------------------------------------
   r13893 | root | 2004-05-11 14:26:51 -0400 (Tue, 11 May 2004) | 1 line

   Use tagged version of src/ZODB
   ------------------------------------------------------------------------

So, when we sync up, I'll probably just recopy (delete and copy) ZODB.

> 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.

I don't see a problem here. In fact, it prevented a headache, because
Philipp's changes didn't accidentally affect the ZODB project.

> 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,

I don't agree.  We have two sane ways: merging and recopying.

 > but implicitly
> creating Zope3- and Zope-specific branches of these modules is very easy to
> do by accident now. 

The branches are explicit.  We always have zope-specific branches. That's
the point. These are effectively like vendor branches, although they are a bit
more convenient.

Non-substantive changes, like these can be easily discarded.

Now, substantive changes are potentially more problematic.  Someday,
we'll probably need to make some ZODB fix to some Zope release branch.
Such a fix will be very explicit.  It should also be easy to either
merge such a fix back into ZODB or to apply some similar fix to ZODB and
resync.

I actually think that the more common way to sync up will be to recopy.
The only thing that would prevent that would be if there are zope-specific
changes to ZODB that were never applied to the original ZODB project. We
wouldn't do that, because it wouldn't be sane.

 > I can't make time to untangle them without dropping
> other work that should be more important than that.

There's nothing to untangle.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org