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.Schoening_at_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
Received on 2013-08-20 22:21:19 CEST