[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

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

 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

>> 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" <wink> 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:


The goal here is to end up with externals on lib/python that do _not_
stitch in "zope", but do stitch in ZODB 3.6.0b1.  If SVN had more
brains, during the merge it would have displayed:

 C lib\python

instead of

 U lib\python

That would have been a huge help.
Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to