title: Reintegrate a branch back to the trunk when sweeping changes have been made to the tree structure
body: <p>A brief note before I start: there is a lot of explanation required to "set the stage", and it may seem like this is more of a design question than a question about a programming problem.  The question is actually about SVN branching and merging, so please read to the end.</p>
  
  <h2>Scenario:</h2>
  
  <p>I have a large Visual Studio solution with quite a few projects.  I'm using SVN, so of course the trunk has my production line of development.  This consists of a core DLL assembly, a "main" UI user client, and a handful of "plugin" assemblies that operate by implementing interfaces on the core assembly in order to provide functionality within the UI, and also by utilizing a set of service methods which provide common functionality to all of the plugins (such as persistence logic operations, storage operations for a centralized file store architecture, etc.)</p>
  
  <p><a href="https://i.stack.imgur.com/AmjRO.jpg" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/AmjRO.jpg" alt="enter image description here"></a></p>
  
  <p>There are also external utilities that I have built over time which must duplicate a lot of the business logic in the plugins.  I won't go into much detail because it will ultimately distract from my main question, but just picture, for example, a scheduled service on a server that handles centralized maintenance operations related to a particular plugin's data.</p>
  
  <p>When I initially built this application, I (stupidly) didn't anticipate the need for centralized service tiers, so I architected the core assembly (for better or worse), as shown above, to be tightly integrated with the presentation layer of the application.  In other words, the UI presentation logic needed to integrate the plugins with the user interface and the business logic needed by the plugins to perform common plugin logic operations is all part of the one "core" assembly.  Therefore, much of the "shared" logic that exists between the plugins and the centralized services has resulted in duplicated code.</p>
  
  <p><a href="https://i.stack.imgur.com/QbMd4.jpg" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/QbMd4.jpg" alt="enter image description here"></a></p>
  
  <p>I decided to undertake the major refactoring initiative to pull out the common logic -- that which is not related to the presentation -- into a "shared" assembly.  For this, I created a branch off the trunk.  I reorganized common code into a "shared" assembly, and I re-pointed everything in the client application (plugins, etc.) and the external service applications to utilize the shared assembly.  In many cases, I also had to rename classes in order to fit their more-general purpose going forward.  The core assembly remained in place only to broker presentation-layer responsibilities between the plugins and the UI.</p>
  
  <p><a href="https://i.stack.imgur.com/g7gFy.jpg" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/g7gFy.jpg" alt="enter image description here"></a></p>
  
  <h2>Problem:</h2>
  
  <p>Now that I have successfully completed the refactoring, I want to reintegrate the branch back into the trunk.  Merging is tricky business even in simple cases, but what I'm facing here is a <em>lot</em> of tree conflicts to put it mildly.  Also, in addition to residing in an entirely new project, the folder structure in the "shared" project is quite a bit different from what it was in the "core" project.  Classes are, in many cases, located in different places due to the new mechanisms for using the shared assembly.</p>
  
  <p>I want to maintain the version history of every class from its old home in the core assembly to its new home in the shared assembly.  Furthermore, I want to guarantee that the merge is successful.  That seems obvious, but in testing a miniature version of this whole scenario, I was never able to get the conflicts to resolve in such a way where my branch features remained entirely intact.  Furthermore, the fact that I have renamed some of the classes, as I stated earlier, to suit their more-general roles, makes it very tricky to maintain the version history.  </p>
  
  <p>I will note that I am using <a href="https://ankhsvn.open.collab.net/downloads" rel="nofollow noreferrer">AnkhSVN</a> which helps in "normal" cases when you rename files to repair the moves, but it doesn't seem to work in these major tree-conflict cases.  Also, I know there is a difference in how merges work between different versions of SVN -- I believe it's pre-SVN 1.5 and post-SVN 1.5.  I'm using SVN 1.9.3.</p>
  
  <p>I have been trying to figure this out for a few weeks now.  I've been pouring through <a href="http://svnbook.red-bean.com/" rel="nofollow noreferrer">the SVN book</a>, <a href="https://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-merge.html" rel="nofollow noreferrer">TortoiseSVN resources like this</a>, and anything I could find from google searches, like <a href="https://stackoverflow.com/questions/1008681/svn-unable-to-merge-branch-back-into-trunk-numerous-tree-conflicts">this</a>, <a href="https://stackoverflow.com/questions/17211072/how-do-i-resolve-the-tree-conflict-when-merging-branch-with-trunk-in-svn">this</a>, and <a href="https://stackoverflow.com/questions/16367990/svn-branch-merge-tree-conflict-issue-using-tortoise">this</a> -- among many, many, many others.  I feel like I'm going crazy and I think advanced SVN (and Tortoise) are impossible to learn with the traditional teach-yourself, learn-from-the-web-and-books approach.  At any rate, I would greatly appreciate any insight that is out there.</p>
  
  <p><strong>What is the proper methodology when you create a feature branch using SVN and plan on making major tree changes and "moves" (i.e. renames) so that you can reintegrate those changes with the trunk without losing anything?</strong></p>