When I'm doing a TortoiseSVN merge, it includes a bunch of directories, and some files into the modified files, even though there are no actual changes.
It changes the property svn:mergeinfo.
Is there any reason why these properties set on the directory/files are needed? Is there any way to get around not doing these changes to svn:mergeinfo?
I usually just revert the items then commit, but this wastes extra time.
That is happening, very likely, because those files and directories have the svn:mergeinfo property set from a previous merge. I don't think it's generally a good idea to merge individual files or directories in a way that causes the mergeinfo to be written to individual files. You should get into the habit of merging at the highest level possible for your workflow, so that the mergeinfo property is only set on structural directories, such as /trunk or /branches/1.0.
However, if you do find yourself with mergeinfo properties on individual files and folders, there are two things you can do: the first thing is simply to remove the svn:mergeinfo property from the files and directories in question. I'm not sure this is recommended unless you really know what you're doing, and what the effects might be. Read the documentation before you do this!
The second thing you can do is commit the property changes the way SVN wants you to, which, if you trust the software, is probably the right thing do.
That having been said, I've been working with my teammates to get in the right habits so that we don't have this annoyance any more.
This should be fixed in SVN 1.7. From the release notes:
Merges no longer record mergeinfo (describing the merge) on subtrees (that have their own explicit mergeinfo), if the subtree was unaffected by the merge. This should greatly reduce the number of spurious
svn:mergeinfoproperty changes for users who have large numbers of subtrees with explicit mergeinfo.
What happens is that once a file/folder has explicit mergeinfo, each subsequent merge to the branch will update that mergeinfo even if the file/folder is unrelated. This is annoying as it introduces more and more clutter in the changelist for each merge.
To avoid this, only merge to the "root" folder of the branch, for example "/branches/maintenance2.x". None of the files or folders below "/branches/maintenance2.x" should then get mergeinfo. Follow the merging advice in the SVN book.
Unfortunately, even if you merge only at the "root" folder of the branch,
empty svn:mergeinfo properties can still appear on individual files and
folders when they are copied, to indicate that they have not received the
same merges as their siblings.
It is probably safe to delete the superfluous subtree mergeinfo. One way to do this is by doing a recursive deletion of the svn:mergeinfo property on each file and folder in your project root. (But keep the mergeinfo on the root folder itself!)
Alternatively, you can upgrade to Subversion 1.6. I have verified that it fixes this issue. It even seems to delete superfluous mergeinfo added by earlier versions for you.
Judging from the comments there are still cases in SVN 1.6 where superfluous sub-tree mergeinfo appears. But I have not been able to reproduce that.
svn:mergeinfo is the property Subversion uses to track merge history. I'd just let it do what it has to do... you might need merge history tracking later and discover that it doesn't work because you didn't commit those properties.
The command given in Stack Overflow question Remove unnecessary svn:mergeinfo properties will remove any extra mergeinfo.
From the root of the project do:
svn propdel svn:mergeinfo -R
svn revert .
svn ci -m "Removed mergeinfo"
I would add that at least one part of this bug was fixed in Subversion 1.5.5. From the 1.5.5 CHANGES file:
do not create mergeinfo for wc-wc moves or copies (r34184, -585)
That is, there was a bug in SVN prior to 1.5 where it would create mergeinfo entries that it didn't use, and were superfluous, and this is likely what the original questioner was hitting if they had a lot of svn:mergeinfo properties.
We removed it recursively on our project because just about all files had this info which made mergeing very annoying (if only one file had been altered, all files had to be merged). From now on we'll only merge on the root, which should avoid this situation in the future.
It hasn't given us any problems so far. Logging is still available on files and seems to be the same (but do it at your own risk anyway!).
Oh, we did it on our trunk, just before making a new branch. This way, we can start from a clean slate.
Great question and answer! We've been having this problem lately, because we're trying to work around limitations of our automated build system. Our build system auto-increments the .bdsproj and some of the .dpr/.dpk files with version and path information.
I want to change that... but right now, if you want to merge one branch with another, you get the handful of files that you changed, and then 1000 files that the build machine changed. So we've been doing "targeted" merges, sometimes a file at a time. Especially with .dpr or .bdsproj files that have legitimate changes (such as the inclusion of an extra unit). Now I know what's going on, so I can hopefully put a stop to the madness.
Thanks Stack Overflow!
