Guten Tag John Maher, am Dienstag, 20. August 2013 um 19:33 schrieben Sie: > For example, when I switch to branch P it switches OK.
Where did you switch from? Does this branch contain the directory which is responsible for the later mentioned error message? It has been created by someone of course, either by svn because it's part of branch or by something other like a build tool. > 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". Which is correct behavior as the director is present, but not versioned. > 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. Surely because it contained unversioned data itself and therefor couldn't be deleted by svn as it tries to never delete unversioned data. > 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. Of course, that's what resolve is meant for ;-), but the interesting thing is the data in the directory. It may not contain all the files and dirs need from your branch E where the directory is versioned in. > Then I switch to branch P. Then is says "local delete, incoming > delete". Why it has a local delete is beyond me. This could be because your conflict resolution which may be missing data which should be present in the director yin branch E, an is not in your local working copy. This means something has changed but didn't get committed because you switched instead of first committing the changes from your conflict resolution. > 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). You never lose code unless you lose your repo, the only thing may be that you don't know how to revert to older revisions. ;-) And yes, I often have the same problem using the console applications and prefer using Tortoise instead in those cases. > Then I switch to branch E. No conflict. Of course, because the directory is missing, which is different to what you have described in the start: You switched to branch P from some other branch, which contained the directory and it surely did contain unversioned files which prevented svn from deleting the directory on switching to branch P. > 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. That's the info which should have been in the first mail and the start of this one. :-) > I have no control over this as the > compiler puts them there. They are on the global ignore list. And subversion can't know how important those files are for you and therefor can't just delete them. This problem is up to you, you need to delete them on your own after switching to branch P if you don't need the directory in your working copy. > My question is how to properly handle this? Or is branching > unusable in this situation with out the extra hassle? As subversion can't know what to do with unversioned files, it leaves them as they are where they are. It is up to you to clean up your working copy in such a way that it doesn't contain any mess which prevents you from switching between different branches. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...........05151- 9468- 55 Fax...............05151- 9468- 88 Mobil..............0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
