Subversion marks unmodified files as modified

Question

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:

1. In my branch I commit 1 modified file
2. In trunk I merge in that commit
3. 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.

Answer 1

I do frequent merges for production branch of my project, usually once every week. Never faced a problem like this.. no clues :( .

Seems like some problem with your client

Answer 2

It might be some kind of property change, possibly some automatic modification of the svn:mergeinfo attribute. You can tell if it's a property modification by running "svn stat". If the "M" is in the first column, it's changes in content, if it's in the second column, it's property changes.

Answer 3

The change is in the file properties. If you run svn proplist, you will see a lot of mergeinfo entries. This is because svn tracks merges in file properties. This is a new feature from 1.5, so it didn't occur in older versions.

I have never completely understood the exact reason why this happens, but it has to do with the internal implementation leaking through. Trying to understand it without understanding how svn is implemented is, as far as I have concluded, not possible. However, usually the root cause has to do with subtree merges. Eg. If you merge the changes of a subdirectory or a single file, rather than the entire branch/tag. In order to track what has been merged, subversion will put the mergeinfo property on the most general node, but apparently it's not intelligent enough in picking it. You can fix the problem by manually editing mergeinfo. Simply remove the property from all nodes below trunk, and make sure that trunk has all the merged revisions in its mergeinfo. Of course, this means that you have to make sure that the changes has actually been merged.

All in all rather confusing, but the good news is that the svn devs actually are working on making the whole thing more smooth.

Answer 4

What happens is that once a file/folder has explicit mergeinfo (i.e. a svn:mergeinfo property), 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: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.

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:mergeinfo property on each file and folder in your project root.