There is a wrinkle about performing this merge that eluded my memory until now. To support multidatabases within Zope, it was reasonable to change ZODB.config.ZODBDatabase to support the heretofore likely-unused-by-real-world-code "databases" and "database_name" options that may now be passed into ZODB.DB's constructor: http://svn.zope.org/ZODB/branches/blob-merge-branch/src/ZODB/config.py?rev=3... The current blob-merge-branch code depends on this change being available in the ZODB revision it uses. In case you're interested, the code that actually makes use of this feature in the zodb-blobs-branch is in the Zope2.datatypes.DBTab.getDatabase method. Is this change acceptable for a merge into the ZODB HEAD? - C On Wed, 2005-10-19 at 01:02 -0400, Chris McDonough wrote:
On Tue, 2005-10-18 at 22:21 -0400, Tim Peters wrote:
[Chris McDonough]
I think I may need some remedial SVN help because I don't want to do this in a stupid way. Hopefully someone will be willing to guide me through this.
I'll be in FB tomorrow if you'd like to pair on it (while in theory Jim might object, I think he thinks getting this done is important enough to offer real help -- especially if he doesn't have to offer it himself <wink>).
Thanks for the offer! I won't be able to visit ZC world HQ tomorrow, though unless you'd be there and willing to start around 10pm. "Other duties" is my official excuse but I'm also horrified by the idea that I'd be expected to wear pants if I came over there. That's just uncivilized. :-)
The zodb-blobs-branch contains code that use Tim's multidatabase support for mountpoint support rather than the older DBTab code which monkeypatched ZODB and did other nasty things. It contains a few other ancillary changes that make it possible to use a HEAD-ish ZODB package in Zope 2 as well (including changes to the setup.py I mentioned which allows a newer ZODB to be compiled).
Check. Question: does zodb-blobs-branch contain anything you _don't_ want to see on Zope trunk now? You didn't mention anything like that here.
No (save for inappropriate svn:externals to ZODB and ZEO).
- merge the changes that have happened since September 25 on the Zope 2 trunk into the mountpoint-merge-branch
Why? It may create headaches and I don't see the attraction. Have people been checking in changes to the same files over the last 3 weeks? Even if they have, conflicts are probably easier to deal with when the new branch gets merged back to the trunk.
No, people haven't been changing the same files (except for maybe setup.py) so seems like good advice. This is really what I needed to understand.
But I've read the Zope SVN FAQ and it frowns on the practice of merging trunk changes into a branch and back again.
That's because it's so easy to lose track of what you're doing then. It probably can't be avoided on very long-lived branches, but this branch is only several weeks old now, right?
Yes. The zodb-blobs-branch can just die after this merge if there's a way to get delete branches entirely. If there is to be a long-lived branch, it will be the "blob-merge-branch" of ZODB.
Given that Zope 2.9 is not going to ship with blob support due to feature freeze, I think this means that we have until May to allow the blob-merge-branch to get utterly out of sync with the ZODB trunk. We can then easily wait until, say, the last week in April to worry about issues caused by that desynchronization. The work necessary to remerge should provide just the appropriate amount of delay to allow blobs to miss the next major Zope release. ;-)
Also, what is the "right" branch of ZODB to use in the svn:external for lib/python/ZODB so I can test that it all works ok before I actually perform the merge to the HEAD?
I never leave a Zope pointing at a ZODB branch -- only at a ZODB tag. The only two suitable tags at this time are
ZODB/tags/3.5.1 and ZODB/tags/3.6.0a4
Either should work fine for you. If you use the latter, it may save me some time later ;-) But in either case, it won't last long (I'll have to stitch in a 3.5.2 beta or 3.6.0 beta soon anyway, and tags for those don't exist now).
Great, that's what I needed to know.
Thanks Tim!
- C
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )