subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Reedick <Andrew.Reed...@cbeyond.net>
Subject RE: Switching
Date Tue, 20 Aug 2013 14:17:21 GMT

> From: John Maher [mailto:JohnM@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.



Mime
View raw message