Mysterious non-change showing up in TortoiseSVN / TortoiseMerge

Question

I use TortoiseSVN for version control. In a working cooy I have been working with for weeks, I suddenly see a number of "changed" files showing up in the "SVN commit.." dialog that I have definitely not touched and which do not contain any real differences:

I have not changed these files' encodings not performed any other operation on them as far as I can remember. Does anybody know what this is and how to get rid of it?

EDIT: The behaviour has appeared again. Tortoise is claiming "text change", even though there was none:

this can hardly be a line ending thing, can it? It's not urgent as it happens very rarely now, but I'm still curious.

Edit: All right folks, time to own up. It's really embarrassing but I found out what it was. What I didn't point out, because I thought it wasn't important, was that I was not working in the "commit..." dialog of Tortoise, but in "check for modifications". I think you can gather the rest: I switched back and forth a lot between the IDE and Tortoise, checking in various files, and whenever I would check in a file, not click refresh, do something else and check it in again because I forgot, it wouldn't work - but would of course still be in the list. Thanks for your time! +1'ing every answer and accepting the one who stuck with me the longest :)

Answer 1

Did you maybe use the new "merge-tracking" feature of SVN 1.5+? When merging, it will add/change the property svn:mergeinfo for the files involved, even those that were not changed. These then show up as changes to be comitted.

See http://svnbook.red-bean.com/en/1.5/svn.branchmerge.basicmerging.html#svn.branchmerge.basicmerging.mergeinfo .

Answer 2

The line endings may change if your text files don't have the svn:eol-style property set to native, and if you just opened them in an editor, then saved them.

Some editors and tools automatically convert files to their native EOL version (for example changeing LF end of lines to CRLF).

Check this link to have a complete description on this property.

The svn:eol-style must be set manually on each text file, which is why there is a way to do that automatically by file extension by editing the client configuration file - use TortoiseSVN settings, general settings, Edit subversion configuration file; or check this link and look for the enable-auto-props entry.

Answer 3

Look in the Repo-browser. There are columns to show whether a file's contents have changed, or whether a file's properties have changed. It sounds like maybe the properties have changed but not the file.

Answer 4

All right, let's get out the big guns. :-)

Check out the file (styles.css revision 40) into a separate directory.

Run a program which calculates md5 (e.g. md5, md5sum, or openssl md5) on both your working copy and the repository copy. If you end up with different answers, the files are different and TortoiseMerge isn't showing you something important. If you end up with the same answer (neglecting the infinitesimally probable case where two different but very similar files have two identical md5 hashes), then the files are apparently identical and TSVN has some problem. (maybe it's looking at the file date?)

edit: The only pathological case that crosses my mind is that maybe the file has a different encoding (e.g. UTF-8 vs ASCII)... I upgraded from WinXP SP2 to SP3 several months ago and occasionally I run into weird things (apparently UTF-8 byte order marks) where the first few characters show up strangely in text editors.

Let us know what you find!