> 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.
