Menu
The question of how you can merge individual files in SVN has been answered before, so my question is: Is it safe to do so? Will SVN "get" that specific files have already been merged if I end up merging the whole branch at some point? And what if I merge changes back and forth before I merge the whole branch?
287
And when you're completely finished with your branch, your entire set of branch changes can be copied back into the trunk. In Subversion terminology, the general act of replicating changes from one branch to another is called merging, and it is performed using various invocations of the svn merge subcommand.
TortoiseSVN helps you through this process by showing the merge conflict dialog. Figure 4.58. The Merge Conflict Dialog. It is likely that some of the changes will have merged smoothly, while other local changes conflict with changes already committed to the repository. All changes which can be merged are merged.
Yes, you can merge individual files, but it's usually considered bad practice to do so.
The problem is that Subversion uses the svn:mergeinfo to track merges. If a file doesn't have this svn:mergeinfo property, it uses the svn:mergeinfo of a parent directory. When you merge individual files hither and thither, all those files now get their own svn:mergeifno property on them.
Does this cause a real problem? No. Subversion works fine. The problem is merely perceived. Every time Subversion updates the svn:mergeinfo property, it creates another version of that file even though the contents of that file haven't changed.
Where this is a problem is when you do a merge of a trunk to a branch (or visa versa). You run a command like this:
$ svn merge http://svn.mycorp.com/svn/project/trunk .
You see 100+ files that were modified, but you know that only 3 or 4 files should have been merged.
Examining these files, you discover the only difference is that the svn:mergeinfo property was changed to show that you've merged the latest stuff to these files (even though it doesn't change the content of the file themselves). No real issue. Simply allow Subversion to update these files' svn:mergeinfo property on the commit, and everything is fine. Yes, the merge will show 100+ files were changed in the commit if you do a svn log, but a careful review will show you that only their svn:mergeinfo properties were changed.
What you should not do is revert these files. That will mark that the changes weren't merged into those files (even though it didn't change their contents). Next merge will attempt to remerge the previous merge and cause even more havoc.
Sometimes when developers see this they start complaining to me about the modifications. After all, why are these files modified if there's no change in the file themselves? They get frustrated by all of the svn:mergeinfo changes.
That's why it's considered best practice to always merge at the root of your project and not individual files. This way, only the directory at the root of your project gets the svn:mergeinfo property, and all of the other files in your project will simply use that svn:mergeinfo property.
If you and all of your developers understand this, and are willing to put up with this behavior, there's no problem with merging individual files. It's just not normally done because of this complication.
113
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
