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
