From: Andrew Reedick <Andrew.Reedick_at_cbeyond.net>
Date: Tue, 20 Aug 2013 10:17:21 -0400
> From: John Maher [mailto:JohnM_at_rotair.com]
That doesn't make sense. If you branched (i.e. created copies of a baseline) then the dir trees should be identical. Extending/modifying the library (adding new dirs) shouldn't create a conflict for svn switch, unless you modified the same directory tree/structure in the workspace's branch and in the branch you're switching too. This happens if you 'svn add' the same dir in both branches. Example:
> local unversioned, incoming add upon switch
This sounds like you have a normal, unversioned directory in the workspace. As part of the switch, svn wants to add a versioned dir of the same name to your workspace. You should be able to rename the local normal dir to a new name in order to let the add operation be run unimpeded. I would 'svn revert -R' the entire workspace, rename the normal, local dir, and re-run the switch. And figure out why you have a normal, unversioned copy of the dir in the first place.
> This may or may not be what is supposed to happen, that would be the first thing I would like to know. How to fix it would be the second thing that I would like to know. According to the help of the resolve command says:
Meh. Resolving tree conflicts is a bit of a manual process. IIRC, to resolve it, you would need to
The main takeaway is that resolving tree conflicts isn't as easy as resolving file conflicts. File conflicts let you use the 'mine-full', 'theirs-full', etc. options, but tree conflicts do not. Fixing tree conflicts requires fixing up the tree in the workspace yourself and then using 'svn resolve --accept working' to tell subversion that the tree is now in the state you want. In other words, you have to manually implement 'theirs-full'.
> I did not want to lose the library from the working copy so I switched back to the other branch and then switch back. Now it says:
> local delete, incoming delete upon switch
You (or the failed 'svn switch' command) ran 'svn delete some_dir' in your workspace. However, the current 'svn switch' also wants to run 'svn delete some_dir'. So svn switch is complaining that it can't delete the dir because it's already flagged for deletion. =/
> It seems I did something wrong. My next step would be to add the library back, but that may not be the best response. Any suggestions?
It sounds like you mangled the switch with too many hacks while trying to fix it, i.e. the workspace is a mess. Just 'svn revert -R', then 'svn status' to make sure that there are no local/private files that could muck up the switch.
The thing to remember is that svn is replaying changes on top of your workspace. It walks the revisions, and for each revision, applies that revision's changes to the workspace. So if you're applying 10 revisions' worth of changes and the second revision breaks the switch/merge with a tree conflict, then you have to manually fix the tree conflict (svn add, svn rm, svn revert, etc.), resolve it, and then re-run the switch/merge to apply the renaming 8 revisions.
 Before you run 'svn revert -R', run 'svn status' to make sure you don't have any modified, uncommitted files that you really care about. Revert will delete those changes.
This is an archived mail posted to the Subversion Users mailing list.