0

I am using SVN merge (two different trees) to merge trunk to a feature branch.

I am selecting source as trunk and target as featurebranch and doing it from a featurebranch local workspace(golden, exact copy what is in SVN).

I have a new file file1.xml in featurebranch which is not there in trunk. While merging I am getting a tree conflict saying merge tried to add the new file but it was already there in local.

My problem is, why the merge is even worrying about the new file in feature branch when my source is trunk which doesn't have this file.

I want to make sure the merge happens correctly before I checkin. Any help is highly appreciated.

Narayanan
  • 51
  • 4

3 Answers3

1

You are complicating things by using a "two different trees" merge instead of a simple "normal" merge.

What you are telling SVN by using "two different trees" is "take the changes needed to take trunk and change it to my branch, and apply those changes to my working copy". This is not what you want, because then you are undoing any changes on trunk, and then redoing all your branch changes.

The opposite is also not what you want, I presume, where the opposite would be "undo all my changes on my branch, and do all the changes on trunk, to make my working copy match trunk."

If I understand, what you really want is "take all the changes on trunk that have happened since I branched, and apply them to my working copy". For this, all you need is to merge trunk, to your working copy. The URL of your branch will not appear in the merge command at all. This is the first form of merge documented in the SVN book.

Ben
  • 8,725
  • 1
  • 30
  • 48
0

Note: This answer only applies when your branch was not directly created from trunk. When branching from trunk, see the answer from @Ben

Merge two different trees is to be read as diff and apply. If you want to bring the branch to the same level as trunk you want to take the diff between your branch and trunk and apply it to the branch (basically your working copy). This means, source = your branch and target = trunk.

Example:

svn merge https://svn/repo/branch https://svn/repo/trunk c:\svn\branch

This command will take a diff between the branch and trunk and apply the differences to the working copy for branch. (branch working copy will now be the same as trunk)

If you want to apply the changes done in trunk to your branch (and it is a baseless merge) you need to specify the range of revisions you want to merge.

An example:

svn merge -r 10:HEAD https://svn/repo/trunk c:\svn\branch

This will take the diff between the HEAD revision and revision 10 of trunk and apply that to branch. Basically applying the changes done between those 2 revisions. I suspect that this is what you want to do.

I recommend reading http://svnbook.red-bean.com/en/1.8/svn.branchmerge.advanced.html and doing merges from the command line. TortoiseSVN merge dialogs are a mess.

Filip De Vos
  • 11,568
  • 1
  • 48
  • 60
  • Thanks for the response Filip. Yes I want to merge changes made in trunk back to branch. I am confused though, how can branch be the source in this case. – Narayanan Feb 06 '15 at 20:04
  • Your terminology is confusing. The SVN manual specifically refers to both URLs in a 2-source merge as sources. The "target" is always your working copy. I think this form of merging is intended to get the differences between two branches into a third branch, correct? In this case, the more correct merge would be a simple 1-source merge. – Ben Feb 08 '15 at 18:11
  • Indeed, it should be a 1-source merge. (I got distracted by the two different trees comment in the question, thought it had to be a baseless merge) I will update my answer to make this clear. – Filip De Vos Feb 09 '15 at 08:44
0

You didn't give us too much information about what's going on. It would be nice to have a bit more detail in your scenario, and the exact error message you're getting. Did you do a fresh checkout? What commands are you using to do your merge? What version of the Subversion client and server do you have?

Otherwise, there's not much we can do to pin point your issue. Merging a trunk into a feature branch that is from trunk should usually merge without any issues.

The first question I have is how you created your branch. When you create a branch in Subversion, you should create it using svn copy in the URL form:

$ svn copy --parent $REPO/trunk $REPO/branches/feature

I've seen where people branch by creating a branch via svn mkdir, then copy the files they want on that branch, then add all of those files on the branch. Subversion cannot do a merge of those items because it has no idea of their shared history. To Subversion, these contain completely different files. They might have the same name and similar content, but they're different files. Merging just won't work.

  • So , did you create your branch this way? If so, you're doing good.

  • The second question: Did you branch your feature branch directly off of trunk? That's not a requirement, but merging is much cleaner if the branch you're merging to is off of the branch you're merging from.

  • Third question: Is your feature branch a clean checkout. Does svn status --no-ignore show you anything? Have you done a svn update on it? Making sure your working copy is clean saves you a lot of trouble. In fact, I advise developers just to do a fresh checkout if possible.

  • Is your Server Subversion version and your client Subversion 1.6 or greater. Merge tracking was added in version 1.5, but it was sort of a hit or miss affair. Both the client and server should be at least version 1.6. (The current version is 1.8 and version 1.9 is almost ready to be released, so version 1.6 is pretty old).

If all of these are true, merging should be very simple. You check out the feature branch. Then, you merge trunk into the feature branch.

$ svn co $REPO/branches/feature
$ cd feature
$ svn merge $REPO/trunk

Subversion merges are usually a three way affair. You compare what is on trunk with what is on the feature branch, and what the last common ancestor of the two versions looked like. By looking at the original file before branching took place, Subversion can know what branch the change took place on, and whether it should be considered part of the merge.

Things get a bit tricker in Subversion merging because directory changes are also examined.

In your scenario, I can imagine something like this:

  • In the original last common ancestor directory, that file was there.
  • In trunk, the file was removed.
  • It was also removed from the feature branch, but then added back in.

Now, Subversion tries the merge. The last common ancestor has that file. Subversion looks at the trunk, and sees that file was removed. Subversion looks at the branch, and sees that the file was added.

So, Subversion sees a conflict. It was added on the feature branch since the last common ancestor, but it was also deleted off of trunk. What should it do? It can't simply delete the file since it was added in the feature branch. Since a change happened in both trunk and the feature branch, a conflict has occurred.

This can also occur if you happen to have a file that's not in Subversion in your working copy. (Like a data file), and a file like that was deleted on trunk. Subversion wants to delete the file, but can't. This is why it's so important to start with a clean checkout of the branch you're merging into.

There could be other reasons you're getting this too. It's hard to say. Do a clean checkout on the feature branch. Make sure that svn status -no-ignore returns nothing. Make sure that you're working copy is completely up to date. Do a svn up on it.

Then, if you get an error message, give us the complete error message. Check your trunk and see what it looks like. Also run the following two commands on your feature branch working copy:

$ svn mergeinfo --show-revs eligible $REPO/trunk
$ svn mergeinfo --show-revs merged $REPO/trunk

The first will show you the revision on trunk that are eligible to be merged. The second will show you the versions that were previously merged.

Then, look at the log of those changes and see if you can see any issues. Sometimes I'll see a bugfix on the trunk and also on the branch. These are two separate versions, but fixed the same issue, so the trunk revisions where this bug was fixed should not be merged into the branch. You can do a svn merge --record-only -c $rev to merge those revisions into your feature branch, so Subversion doesn't try merging them again.

David W.
  • 105,218
  • 39
  • 216
  • 337