If you merge a specific set of revisions from trunk into a branch with subversion, what happens?

Question

If I make changes in the trunk to 3 different files, say revisions 40, 45, and 47 respectively, where none of those files have changed since revision 15, how can I merge those revisions into the branch (made at revision 30 and unchanged since) so that I get just the changes between rev 15 and rev 40, 45, and 47 for each of the respective files?

Other changes have been made at the in-between revisions(obviously) but they do not affect the files in question, and I do not want those changes to show up in the branch.

Answer 1

If you only made changes to those files in those commits, then just go ahead and merge those revision numbers. If other files were changed in those commits, and you do not want those changes, I would probably go ahead and do the merge anyway, and then revert changes on the files you do not want modified, then do the commit.

Answer 2

In our system we do merges like this constantly. For the most part everything works great.

You can run a merge on all three revisions and as long as the changes are not interdependent you are all good.

Using TortoiseSVN makes it easy because you can simply specify 40,45,47 as the range match. Otherwise just issue a separate svn merge for each revision statements and it will pull it all together.

If the changes you are not pulling in affect the same lines, you will get a merge conflict. That is the best case scenario, because it means you immediately need to look at it to resolve the conflict. However, as always, just because it wasn't a conflict, doesn't mean you won't get some logic error at compile/run times.

I personally do several hundred of these a week, all with an automated script. Because of how our code is structured (a large repository where most changes are not affecting the same files) we only get a few conflicts a week.