I had some problems earlier today when I tried to create a
1.7.x-issue4032 branch when a branch of that name already existed. That
caused the directory 1.7.x-issue4032/1.7.x to get created on the server.
I didn't notice and switched my 1.7.x working copy to the
1.7.x-issue4032 branch. Instead of simply reporting the new revision
switch started to pull in the new 1.7.x dir, at which point I realised
something was wrong and interrupted the switch. I then ran cleanup in
the working copy.
Next I fixed the repository by deleting the 1.7.x-issue4032/1.7.x
directory, and then I repeated the switch. This resulted in the partial
1.7.x directory in my working copy becoming a tree conflict. At the
time I didn't think too much about this, I resolved the conflict by
running 'svn rm --force' and then 'svn st' showed no changes. Looking
back I suspect the working copy may have been broken at this stage.
Then I switched my working copy back to 1.7.x, moved the 1.7.x-issue4032
branch to 1.7.x-issue4033, created a new 1.7.x-issue4032 branch and
switched my working copy to the new 1.7.x-issue4032 branch.
Everything looked fine until I attempted to merge into the working copy,
at which I got a "mixed revision" error. At this point:
svnversion showed: 1186664:1186669M
svn st showed: nothing
svn up did: nothing
svn merge complained: mixed revision
Using sqlite3 I can see that I have 125 NODES rows corresponding to
nodes in the 1.7.x-issue4032/1.7.x directory that no longer exists.
These rows were all at revison 1186664 and were unchanged by update.
Unfortunately I've just accidentally deleted the corrupt working copy
so I can't investigate it further. I haven't yet tried to reproduce
it.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Received on 2011-10-20 11:29:14 CEST