RE: Switching

> From: John Maher [mailto:JohnM_at_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.
Received on 2013-08-20 16:19:18 CEST