Thanks for your reply. I agree it does not make sense. But it is reproducible. The dir trees are NOT identical because one branch has a library that the other does not. In normal use I would expect the branches to differ. And I assure you one of the branches does not have the directory causing the trouble, I checked on the server.
So the branches are different and it appears impossible to switch between them without conflicts. For example, when I switch to branch P it switches OK. An svn status on the problem directory shows it with a '?'. Then I switch to branch E and get a conflict. It says "local unversioned, incoming add upon switch". The local should be unversioned, it is not part of branch P. I do not know why the directory did not get deleted during the switch. An svn status shows the directory marked for deletion. So in one instance of time I get a message of a directory that is unversioned, incoming add, marked for deletion. Svn revert does not do anything useful. So I then issue svn resolve --accept working UI_Email where UI_Email is the directory causing the problems. This clears the conflict. Then I switch to branch P. Then is says "local delete, incoming delete". Why it has a local delete is beyond me. That folder is part of the branch, I want it there and never issued a delete. But subversion did. So I resolve this conflict the same as the last one and switch back to branch E. You guessed it, conflict again. So I resolve the conflict then commit and decide to let subversion delete the directory (I have a backup because I've lost code to subversion before). So now my code is gone. I delete the directory with supporting files. Then I switch to branch P. Success for now (I know failure is just a matter of time). Then I switch to branch E. No conflict. But I won't get my hopes up yet, I still do not have the new library included which was the whole reason for creating the branch in the first place. So I copy over the directory and do a svn add then commit. Then I can switch to branch P. This is where the problem arises. Subversion deletes the files but not the directory because it contains files that do not belong in subversion. I have no control over this as the compiler puts them there. They are on the global ignore list. Now when I switch the conflict returns. Nothing in the book explains how to handle this. Searching comes up with all kinds of irrelevant stuff and unanswered questions. My question is how to properly handle this? Or is branching unusable in this situation with out the extra hassle? Thanks JM -----Original Message----- From: Andrew Reedick [mailto:andrew.reed...@cbeyond.net] Sent: Tuesday, August 20, 2013 10:17 AM To: John Maher; Subversion help Subject: RE: Switching > From: John Maher [mailto:jo...@rotair.com] > Sent: Monday, August 19, 2013 1:31 PM > To: Subversion help > Subject: Switching > > Hello, > > I want to thank all who have been helpful. I have gotten my test project to > merge branches successfully. Now I am trying it on our production code and > wish to make sure I am not making any mistakes. > > I use one folder for my source code (all branches) mainly because of vendor > requirements the code must be run from the same directory. I have created > two branches for two new features. One feature extends an existing library. > The other feature adds a new library as well as extending an existing one. > When I switch I create a conflict because the directory exists in one branch > and not the other: 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: Bad, causes conflict: svn add ^/branches/foo/new_dir svn add ^/branches/bar/new_dir Good: Svn add ^/branches/foo/new_dir cd to bar workspace; svn copy ^/branches/foo/new_dir . It could also happen if you renamed/moved the same dir in both branches. > 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[1], 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: > > So I tried svn resolve -accept working LibraryDirectory but I believe that > was a mistake because then the directory was marked "Delete" which is not > what I wanted. Does anyone know what is the proper response? Meh. Resolving tree conflicts is a bit of a manual process. IIRC, to resolve it, you would need to 1) rename the normal, local dir, and 2) 'svn copy svn://server/.../LibraryDirectory .' Meaning, you need to manually implement the add. ('svn switch' failed the add so you need to reproduce the add manually.) 3) 'svn resolve' the dir. Which is why I recommend just reverting[1] the switch, renaming the dir and re-running the switch. 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'[1], 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. [1] 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.
