If you merge a specific set of revisions from trunk into a subversion branch, what happens?
If I make changes to trunk in 3 different files, say versions 40, 45 and 47 respectively, where none of those files have changed since revision 15, how can I merge those changes into a branch (made in revision 30 and no changes ) so I only get changes between rev 15 and rev 40, 45 and 47 for each of the corresponding files?
Other changes were made in intermediate versions (obviously), but they don't affect the files in question, and I don't want those changes to show up in the branch.
source to share
If you've only made changes to those files in those commits, then just go ahead and merge those revision numbers. If there were other files changed in those commits, and you don't want those changes, I would probably go ahead and merge anyway, then check in the changes to the files you don't want to change, and then commit.
source to share
In our system, we are constantly merging. For the most part, everything works great.
You can run the merge on all three versions, and as long as the changes are not interdependent, you're fine.
Using TortoiseSVN makes things easier because you can simply specify 40,45,47
as a range match. Otherwise, just issue a separate one svn merge
for each revision statement and it will pull out anyway.
If changes that you do not affect affect the same lines, you will get a merge conflict. This is the best scenario because it means you need to look at it immediately to resolve the conflict. However, as always, just because it's not a conflict doesn't mean that you won't get a compile-time / runtime boolean error.
I personally do several hundred of these a week, all with an automated script. Due to the way our code is structured (a large repository where most changes don't affect the same files), we only get a few conflicts a week.
source to share