svn mergeinfo property, how to find, remove, or ignore

Question

I have a repository with the standard branches/tags/trunk directory structure. The trunk contains some svnexternals stuff (not sure if that matters for this question, just pointing it out in case).

This is a brand new project where we haven't done a release to production yet, so this issue isn't as big of a deal as it will be in a few months.

I'm trying to merge [set of revisions] from our trunk (development) into our test branch. Right now, I'm getting the infamous merge info error. See here for more info. In order to get past this error for now, I'm DELETING the test branch, then re-creating it. But, this obviously is not a good way to go, especially after we start doing more and more builds and code moves to our test branch.

So...I've gone through all of the folders at the test branch level, as well as everything higher up and there aren't ANY mergeinfo properties set. In fact, the ONLY property I found that was set was my svnexternals, on one folder. From the link I put in above, one of the other options says to set the ignoreancestry option. My version of Tortoise defaults that already and it doesn't work.

Is there another approach to finding the mergeinfo property so I can remove it? Or, is there another way to ignore the mergeinfo property so I can get these merge's done instead of blowing away my branch?

Edit: By the way, I'm using Tortoise version 1.8.4.24972 (64-bit)

Edit2: I'm doing EVERYTHING from the TortoiseSVN Gui Client (aka I haven't done anything from command-line)

Edit3: Hi David, I don't do ANYTHING via command-line. Here's the steps that I've tried, and the error: Right-click "test" branch, TortoiseSVN -> Merge...Select "Merge a range of revisions". URL to merge from: ...../trunk, "Revision range to merge" = "all revisions". Ignore Ancestry is true. When I click ok, the error says: "Error, cannot merge automatically while ignoring mergeinfo"

Also, "how do I create the test branch?". If it already exists, I open the TortoiseSVN -> Repo browser. Navigate to the "branches" directory. In the right-side pane, right-click on the "test" branch, select "Delete" and give my comment "merge is hard for newbies". Next, go back to Windows Explorer where my source code is location. Right-click on "trunk", select "Branches/Tags...". Select the location to create the branch/tag, which is ../branches/test. Done.

Answer 1

How are you creating that test branch?

The right way

$ svn cp $REPO/trunk/proj $REPO/branches/branch_name/proj

The wrong way

$ svn mkdir $REPO/branches/branch_name/proj
$ svn co $REPO/branches/branch_name/proj      # This will be empty
$ svn export $REPO/trunk/proj                 # Copy in the files from prom
$ svn add -R .                                # Add the files back in
$ svn commit

In order to do a merge, you need three things:

• Where you're merging to.
• Where you're merging from.
• The last common ancestor between the two.

When you use svn cp, Subversion can track the history of the file from the originating branch (or trunk). When you copy the files in and use svn add -R ., Subversion believes these files are completely different files from the ones you copy them from.

When you do a merge, and the branch was made incorrectly, Subversion is going to hit a lot of conflicts with a lot of local file/remote add errors because Subversion will attempt to add a file to the branch, but already see a file with the same name already there.

Is this a possible that you did an add to create a branch instead of a svn cp? What is the exact error messages you're getting? What version of the Subversion client are you using? Are you merging both from test to trunk and trunk to test or only one way? Are you cherry picking revisions?

---

ADDENDUM: Hi David, I don't do ANYTHING via command-line.

Then, see how that test branch was created. That might help pin down the issue. Select Log Messages for the test branch. On the bottom, deselect the Stop on Copy/Rename. Then look at the oldest revision in the list. Mine looks like this:

Path                 Action    Copy from Path    Revision
-------------------  --------  ----------------  ---------
/branches/5.1/proj   Added     /trunk/proj       12344

Note the Copy from Path column. This shows me that the branch was made by copying the trunk via the equivalent of the svn cp command. If I turn off that Stop on copy/rename, I'll see even more of the log as the history continues down the branch.

One of the big issues I've seen in TortoiseSVN is that it's easy to branch by creating the branch, then dragging the files in trunk's working directory into the new branch and select TortoiseSVN->Add from the menu.

The correct way to create a branch is to right-click on the repository browser on the trunk project, and select copy to... from the context menu. This will present to you a copy to dialog box, and you type in the new URL for the branch.

If you look at Show log, and you don't see that Copy from Path column, but instead see an add for each file, you know that the branch was created incorrectly. This will cause your merges to have problems.

What to do? There's not much you can do. You can Ignore History on the merge which may help, but the svn:mergeinfo will be useless and you'll have to manually track what you've previously merged. Plus, there's a good likelihood that you'll still end up with lots of conflicts.

To do that, select the normal Merge a range of revisions, and on the last screen, select Ignore Ancestry.

If you are making a branch using the TortoiseSVN copy and not via Windows copy and add, there maybe another issue. I'll need to see the exact errors you're getting. There are several issues that will cause merge conflicts. For example, someone makes the same changes on a branch as they did to Trunk. Imagine someone found a problem on the branch, fixed it, and then thought I might as well fix it on trunk while I'm at it. In this case, you'll get a conflict because the same file was added or deleted, or the same lines were changed in the same file. These types of changes can easily be resolved, but are a pain.

To not get those errors, instead of duplicating a change on both branch and trunk, the developer should have merged that one change from branch to trunk (or visa versa).

Does this help?