Refactoring over several branching with a lot of directory structure changes

There is a very large Visual Studio solution (almost 200 projects) which I need to refactor and restructure, merging and possibly dividing many of those projects, altering code...

The issue is - I am to be working on a branch of the code, while several more branches will be moving forward with development. After my refactoring is complete, the changes need to be applied to some of those branches, which might been have drastically changed. Also, my directory structure will changed dramatically, many parts of it renamed or merged.

The question is - is it reasonable to rely on SVN to merge the projects in the future or do I need an external tool? Or perhaps writing my own tool.

Sorry for the basic question, I am relatively new to SVN and not sur开发者_开发问答e if it is the best way to go.

In my experience, relying on SVN merge in stuff like you're going to do (heavy refactoring) the way you're going to do it (working in branches) turned out extremely counter-productive.

Per my recollection, doing things that way lead to developers wasting about 1/4 if not 1/3 time on fixing regression bugs introduced by SVN merge (we've got these estimates from JIRA).

• When I first noticed that issue my initial assumption was that this is just a matter of learning curve - I expected that after gaining sufficient experience we will discover how to do it right. Unfortunately, even after several months of working with the project, "waste rate" steadily kept as high as in the beginning.

Our way out of this mess was to change branching strategy (search the web for something like version control branching strategy if you're interested). Strategy we changed to was unstable trunk (this is also searchable term in case if you're interested). That switch required quite noticeable efforts to prepare and some changes in dev process (more on that below) but overall the result turned out more than satisfactory - IIRC waste rate dropped by more than 4x.

Most notable of changes in dev process I mention above are regular "checkpoint" trunk releases and regression test cycles. We introduced these to act as a replacement to natural checkpoints which were previously enforced by merges.

...or do I need an external tool?

That option looks worth considering, too. I remember discussing SVN merges issues with an ex-colleague some time after my project switched to unstable trunk. He told me that for his current project, switching to better merge tool made a big difference.

Back then I was happy enough with what we had so I didn't mark what tool he referred to. Though there seem to be plenty related discussions at SO, for example:
- What's the best three-way merge tool?
- Tools for SVN Merging
- Better Merge Tool for Subversion

PS. And, no matter how you work around merging issues, having a comprehensive and easy to use set of tests would be really helpful