Re: [Zope-dev] Mountpoints
[Chris McDonough] > This merge has been done. Woo hoo! Thank you, Chris! I since stitched in ZODB 3.6.0b2, which is the most recent 3.6 (internal) release. That didn't seem to create any new problems. > Since "zopectl test " no longer appears to do the right > thing Sorry, never used it, don't know anything about it. > and I can't seem to get test.py to run anything except the entire > test suite, Do test.py -h for help. The -t option will probably help you. For example, """ $ \python24\python.exe test.py -vv -t test_pop Running tests at level 1 C:\python24\lib\whrandom.py:38: DeprecationWarning: the whrandom module is deprecated; please use the random module DeprecationWarning) Running unit tests: Running: test_pop_default (AccessControl.tests.testZopeGuards.TestDictGuards) test_pop_raises (AccessControl.tests.testZopeGuards.TestDictGuards) test_pop_simple (AccessControl.tests.testZopeGuards.TestDictGuards) test_pop_validates (AccessControl.tests.testZopeGuards.TestDictGuards) test_pop_raises (AccessControl.tests.testZopeGuards.TestListGuards) test_pop_simple (AccessControl.tests.testZopeGuards.TestListGuards) test_pop_validates (AccessControl.tests.testZopeGuards.TestListGuards) Ran 7 tests with 0 failures and 0 errors in 0.000 seconds. $ \python24\python.exe test.py -vv -t pop_val Running tests at level 1 C:\python24\lib\whrandom.py:38: DeprecationWarning: the whrandom module is deprecated; please use the random module DeprecationWarning) Running unit tests: Running: test_pop_validates (AccessControl.tests.testZopeGuards.TestDictGuards) test_pop_validates (AccessControl.tests.testZopeGuards.TestListGuards) Ran 2 tests with 0 failures and 0 errors in 0.000 seconds. """ > I didn't create any new tests because I wouldn't have had > the time to create tests and run them iteratively. Sorry to ruin your weekend, then ;-) > That said, all existing tests pass and I did do some interactive > stress-testing of the sessioning mount point, both of which made me feel > comfortable enough to go ahead and do the merge. The tests appear to be in exactly as good shape on Windows now as they were before (there are test failures on Windows; opened a Collector issue about them Thursday), so you have a plausible defense in court. I won't sue you if you won't sue me ;-) ___ 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 )
Re: [Zope-dev] Mountpoints
This merge has been done. Since "zopectl test " no longer appears to do the right thing and I can't seem to get test.py to run anything except the entire test suite, I didn't create any new tests because I wouldn't have had the time to create tests and run them iteratively. That said, all existing tests pass and I did do some interactive stress-testing of the sessioning mount point, both of which made me feel comfortable enough to go ahead and do the merge. Enjoy, - C On Fri, 2005-10-28 at 18:53 -0400, Chris McDonough wrote: > On Fri, 2005-10-28 at 10:12 -0400, Tim Peters wrote: > > Ah, it's the properties on lib/python that are screwing us here! Chris, > > throw > > > > svn revert lib/python > > > > into the mix too. That got me unstuck. The problem is that both Jim > > and I (at least) changed the set of externals listed in lib/python, > > and SVN absolutely sucks at merging property changes. The "revert" > > above gets you back to the externals Zope trunk actually uses today. > > That's vital because Zope trunk stitches in "zope" in an entirely > > different way now. Reverting also stitches in a version of ZODB we > > don't want to use, but after reverting you can do > > > > svn propedit svn:externals lib/python > > > > to put back "the right" version of ZODB for your branch (s/3.4.2/3.6.0b1/g). > > Woo hoo! As always, you are my hero, Tim. That worked great. And it > as a bonus Zope even *starts* after changing the properties and running > svn up. > > - 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 ) > ___ 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 )
Re: [Zope-dev] Mountpoints
On Fri, 2005-10-28 at 10:12 -0400, Tim Peters wrote: > Ah, it's the properties on lib/python that are screwing us here! Chris, throw > > svn revert lib/python > > into the mix too. That got me unstuck. The problem is that both Jim > and I (at least) changed the set of externals listed in lib/python, > and SVN absolutely sucks at merging property changes. The "revert" > above gets you back to the externals Zope trunk actually uses today. > That's vital because Zope trunk stitches in "zope" in an entirely > different way now. Reverting also stitches in a version of ZODB we > don't want to use, but after reverting you can do > > svn propedit svn:externals lib/python > > to put back "the right" version of ZODB for your branch (s/3.4.2/3.6.0b1/g). Woo hoo! As always, you are my hero, Tim. That worked great. And it as a bonus Zope even *starts* after changing the properties and running svn up. - 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 )
Re: [Zope-dev] Mountpoints
[Tim Peters] >>> Jim redid the way Zope trunk stitches in Zope3 since you last looked >>> at this, and that can create some mechanical problems (of the kinds >>> you're seeing, in fact). The svn docs probably won't help. >>> Suggestion (which is repetition of what I suggested before this >>> happened, but we'll gracefully let that pass ;-)): >>> >>> Check out a fresh, new copy of Zope trunk. >>> >>> Merge your branch into that. [Chris McDonough] >> Thank you! >> >> Eagds. I *thought* I had done just that. I had even printed out your >> previous handholding email about this before starting. But no. I did >> not. Instead, to my horror, I realized had *copied* a trunk working >> copy (of an unknown vintage, although up-to-date according to "svn >> status" after an svn up) and then I'd merged the branch into that. >> >> So about a minute ago, I followed your instructions literally, figuring >> that I'd be able to sheepishly move on afterwards, but unfortunately it >> comes out the same. Literally, here are the commands: >> >> $ svn co svn+ssh://svn.zope.org/repos/main/Zope/trunk >> $ cd trunk >> $ svn merge -r 38624:HEAD svn+ssh://svn.zope.org/repos/main/Zope/branches/zodb-blobs-branch Didn't you get any output here? I saved mine the last time I tried it, and I expected you'd see the same (except with Linux path separators): U doc C lib\python\Zope2\Startup\datatypes.py U lib\python\Zope2\Startup\zopeschema.xml U lib\python\Products\ZODBMountPoint\tests\testMountPoint.py U lib\python\Products\ZODBMountPoint\MountedObject.py D lib\python\Products\ZODBMountPoint\Mount.py D lib\python\DBTab\DBTab.py D lib\python\DBTab\__init__.py D lib\python\DBTab\CHANGES.txt D lib\python\DBTab\Exceptions.py D lib\python\DBTab\ClassFactories.py D lib\python\DBTab D lib\python\DBTab U lib\python U setup.py U utilities >> $ svn up >> >> ... which comes out with >> >> >> >> Fetching external item into 'lib/python/zope/thread' >> External at revision 39684. >> >> >> Fetching external item into 'doc/ZEO' >> A doc/ZEO/cache.txt >> A doc/ZEO/ZopeREADME.txt >> A doc/ZEO/README.txt >> A doc/ZEO/trace.txt >> A doc/ZEO/howto.txt >> Updated external to revision 39684. >> >> >> Fetching external item into 'lib/python/zope' >> svn: Working copy 'lib/python/zope' locked >> svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details) Drat. My apologies! Tried again & I see that too. Since we _started_ with current Zope trunk here, and your branch doesn't change anything at or under lib/python/zope, I didn't expect that. I was wrong. >> I am reasonably confident that drinking just one more Yuengling will >> solve this problem in one way or another. Did it work out? I'm ill today and saw this on my way back to bed, but in 5 minutes of trying I didn't find any combination of "rm -rf lib/python/zope" and "svn cleanup" that got me unstuck. Will try again later. [Jim Fulton] > svn:externals suck. A lot. As Tim suggested, you could throw away > this check out and start over. That's what he tried above -- didn't work for him. Doesn't work for me either, but Chris may have clouded my mind ;-) > A simpler thing you could do is to remove the zope directory and do an svn > up. He tried that before and reported endless failures. That's why I suggested starting over to begin with. Should have worked ;-) > Since we switched to using externals, we see lots of things like this. You > just > learn to delete the directories in question. That alone wasn't enough for my own Zope trunk checkout -- also needed to do "svn cleanup". But the "start over from scratch" sequence above appears to leave Chris and me in a state where no amount of directory removal and "svn cleanup" gets rid of Fetching external item into 'lib\python\zope' svn: Working copy 'lib\python\zope' locked svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details) upon the next "svn up" attempt. Ah, it's the properties on lib/python that are screwing us here! Chris, throw svn revert lib/python into the mix too. That got me unstuck. The problem is that both Jim and I (at least) changed the set of externals listed in lib/python, and SVN absolutely sucks at merging property changes. The "revert" above gets you back to the externals Zope trunk actually uses today. That's vital because Zope trunk stitches in "zope" in an entirely different way now. Reverting also stitches in a version of ZODB we don't want to use, but after reverting you can do svn propedit svn:externals lib/python to put back "the right" version of ZODB for your branch (s/3.4.2/3.6.0b1/g). Alternative: I haven't tried this, but it "should work" too, and would be easier: instead of reverting lib/python, do svn propedit svn:externals lib/python and just delete the part stitching in `zope`; that's this line: zope svn://svn.zope.org/repos/main/Z
Re: [Zope-dev] Mountpoints
On Oct 28, 2005, at 9:19 AM, Jim Fulton wrote: svn:externals suck. A lot. As Tim suggested, you could throw away this check out and start over. A simpler thing you could do is to remove the zope directory and do an svn up. That sounds reasonable, but I've done both of those things and no joy yet. I've even switched machines in a hail-mary "maybe it's a local client bug" idea. Since we switched to using externals, we see lots of things like this. You just learn to delete the directories in question. I wish that worked for me. I'm going to try to offer the directory a cold glass of milk laced with arsenic next. We're getting so cozy with each other, I think it might accept. - 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 )
Re: [Zope-dev] Mountpoints
Chris McDonough wrote: Jim redid the way Zope trunk stitches in Zope3 since you last looked at this, and that can create some mechanical problems (of the kinds you're seeing, in fact). The svn docs probably won't help. Suggestion (which is repetition of what I suggested before this happened, but we'll gracefully let that pass ;-)): Check out a fresh, new copy of Zope trunk. Merge your branch into that. Thank you! Eagds. I *thought* I had done just that. I had even printed out your previous handholding email about this before starting. But no. I did not. Instead, to my horror, I realized had *copied* a trunk working copy (of an unknown vintage, although up-to-date according to "svn status" after an svn up) and then I'd merged the branch into that. So about a minute ago, I followed your instructions literally, figuring that I'd be able to sheepishly move on afterwards, but unfortunately it comes out the same. Literally, here are the commands: $ svn co svn+ssh://svn.zope.org/repos/main/Zope/trunk $ cd trunk $ svn merge -r 38624:HEAD svn+ssh://svn.zope.org/repos/main/Zope/ branches/zodb-blobs-branch $ svn up ... which comes out with Fetching external item into 'lib/python/zope/thread' External at revision 39684. Fetching external item into 'doc/ZEO' A doc/ZEO/cache.txt A doc/ZEO/ZopeREADME.txt A doc/ZEO/README.txt A doc/ZEO/trace.txt A doc/ZEO/howto.txt Updated external to revision 39684. Fetching external item into 'lib/python/zope' svn: Working copy 'lib/python/zope' locked svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details) I am reasonably confident that drinking just one more Yuengling will solve this problem in one way or another. svn:externals suck. A lot. As Tim suggested, you could throw away this check out and start over. A simpler thing you could do is to remove the zope directory and do an svn up. Since we switched to using externals, we see lots of things like this. You just learn to delete the directories in question. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ 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 )
