Tortoise SVN - Merge Trunk into Branch - Tree Conf

Question

We are on SVN 1.8 and I'm using Tortoise SVN 1.8 as well.

The main code resides on /project/trunk. I will be doing a large change so I created a branch in /project/branches/x that was a copy of /project/trunk.

As part of the change, I need to rearrange the directory structure to handle multiple clients. Currently the the trunk looks like:

/project/trunk/process/xyz/file1.xml
/project/trunk/process/xyz/file2.xml

I want to change the structure to be more like:

/project/trunk/process/xyz/client1/file1.xml
/project/trunk/process/xyz/client1/file2.xml

I tried right-dragging into the new folder and did a SVN Move Here with the context menu. As I'm working on in the branch, I need to make a change to file1.xml in the trunk for a production issue. I want that change in my branch, but when I tried to do a merge in Tortoise SVN, it comes up with a conflict because the local file is missing.

The options simply give me options to resolve, postpone or abort. What is the best way to get the change from /trunk/process/xyz/file1.xml into /trunk/process/xyz/client1/file1.xml?

I'm kind of a novice in SVN so please be kind :)

Answer 1

Well, you are victim of "Refactoring Hell" in SVN - it's still a Big Problem

You have at least two choices

• Merge (in order to eliminate tree-conflict) not trees (the whole /trunk into /branches/x), but individual files, file1.xml in you case.
  • In WC of branch, select "Merge" for individual file, not parent folder, and trunk's file1.xml as merge source.
  • Repeat these merges for all (moved) files with tree-conflict
• Migrate to Mercurial at least for refactoring
  • (Install Mercurial /TortoiseHG/)
  • Enable (bundled with THG 3.0) hgsubversion extension
  • Clone SVN-repo into Mercurial repo
  • Refactor, merge, commit to local HG
  • (because mergesets can't be pushed back to Subversion) archive tip of Mercurial repo into unversioned files, which must replace WC of you Subversion repository and commit this state of changes (you'll get broken history at this revision in Subversion)
  • Return to work with Subversion repository and refactored code