I created a feature branch because I need to restructure a fairly large project. The feature branch is 70% moving stuff around and 20% modifying code and 10% new code. It looks something like this.
Trunk Branch Actions
2000 = 2001 create branch
| 2002 move lots of file and directories plus a few file edits
| 2003 lots of edits plus a few more file moves
2004 | a few edits to files that have been moved in the branch
| 2005 some more edits and a new file or two
2006 | a few edits to files that have been moved in the branch
| 2007 feature is done... time to pull changes from the trunk
When I try to pull the changes from the trunk into the branch I see a "tree conflict" error and not much else. This is what I found when, I traced a file that was moved in the branch and modified in the trunk.
\old\path\file.txt - trunk version 2006
\new-path\file.txt - branch version 2007
---- I would like ----
\new-path\file.txt - merged trunk version 2006 and branch version 2007
I'm using SVN 1.7 and the latest TortoiseSVN client so I thought the changes would be tracked auto-magically and this wouldn't happen... I guess I was wrong. My first thought is to use the command line to create another branch then merge the changesets one-by-one until I get everything working again but I'm not really sure which arguments to use to do this. I feel like commit 2002 completely destroyed my ancestry/history but I'm not sure.
Any advice on how to resolve this issue?
I thought the changes would be tracked auto-magically and this wouldn't happen...
No, rename + edit on opposite sides of merge will give you tree conflict even in 1.8+ (there merge is slightly improved, contrary to 1.7)
thought is to use the command line to create another branch then merge the changesets one-by-one
Wrong idea. Because you know both sources of tree-conflicts, you have forcibly merge \old\path\file.txt to \new-path\file.txt and only after this mergeset, merge trees \old\path\ and \new-path\ - without tree conflicts
PS - In order to avoid "Refactoring Hell" in Subversion I always recommend refactor + merge refactored separately (in SCM with merge as first class citizen) and just replace WC by content of working dir of Mercurial after successful merge (you can clone SVN-repos, but can't push mergesets back)