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.