[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>).
There exists a branch of the Zope 2 trunk named the zodb-blobs-branch. It was created as a branch of the Zope 2 trunk on September 25 (about 3 weeks ago).
Check.
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.
The zodb-blobs-branch happens to link in an svn external for the ZODB package which currently points to a *ZODB* branch named "blob-merge-branch". This is really the only thing "blob-ish" about the zodb-blobs-branch. All of the changes that actually cause blobs to be supported are isolated in that ZODB branch. The rest of the changes are really just to support a later ZODB revision within Zope. It's likely that this svn external can be changed to point to any 3.6-ish ZODB branch without breaking things too badly.
FWIW, that sounds likely to me too.
So I'd *think* I'd like to:
- create a SVN branch *from the zodb-blobs-branch* named mountpoint-merge-branch
Yup.
- change the svn external for lib/python/ZODB on the mountpoint-merge-branch to point at the proper ZODB revision
Likewise. Be sure to do an "svn up" right after (while only a bona fide idiot could make this mistake, on two occasions so far I've switched to a different external, run tests, and checked it in -- only to realize later that I _hadn't_ done "svn up" so didn't actually test anything new -- heh).
- 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.
- merge the mountpoint-merge-branch back in to the trunk.
Bingo.
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?
Is there a better way to do this other than applying the changes manually to the HEAD?
I'm not sure what this means. As above, my natural inclination is not to try merging anything in the trunk -> branch direction here.
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).