Here’s an odd problem I encountered using Subversion: when merging from a development branch to trunk (or back, for that matter) Subversion would mark a lot of files as changed — while they had no changes.
Here’s what happens:
- In my branch I commit 1 modified file
- In trunk I merge in that commit
- Lots of other files and directories are marked as ‘modified’ without actually having been changed (not even whitespace, line endings, properties or that sort of stuff).
Technically, committing these unchanged changes would make no difference, but I do not want to add noise to my logs.
Any idea what might cause this nuisance, and how to prevent it? Can I ask Subversion why a file has been marked as modified, so I would know if it was the file’s content, properties, etc.?
FYI: subversion client in the 1.6.x range, server in 1.5.x range. Using a combination of Versions.app and the CLI on Mac OS X Leopard.
What happens is that once a file/folder has explicit mergeinfo (i.e., a
svn:mergeinfoproperty), each subsequent merge to the branch will update that mergeinfo even if the file/folder is unrelated. This is indeed 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:mergeinfoproperties 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.If you merge only at the root, then it is probably safe to delete the superfluous subtree mergeinfo. One way to do this is by doing a recursive deletion of the
svn:mergeinfoproperty on each file and folder in your project root.This appears to have been fixed in SVN 1.7. From the release notes: Reduced subtree mergeinfo changes.