1

At my workplace, we use TortoiseSVN (currently on version 1.9.6) to do extensive branching and merging. Every once in a while a file will show up in the log as modified as part of a merge commit:

>svn log -r 86212 --verbose
------------------------------------------------------------------------
r86212 | user1 | 2018-05-15 16:18:09 -0400 (Tue, 15 May 2018) | 1 line
Changed paths:
   M /path/to/file/MySpecialFile.pas
   M /path/to/file/ANormalFile.pas

but there are no differences at all (that I can find) in MySpecialFile.pas. The file properties have not been changed, no whitespace differences, and we use Windows OSs exclusively, so there is no reason for the Unix/Windows end-of-line mismatch. In fact, if I use the "Diff with previous version" option, it skips right over the revision in question, and using the SVN diff does the same:

>svn diff MySpecialFile.pas -r HEAD:PREV
Index: MySpecialFile.pas
===================================================================
--- MySpecialFile.pas (.../path/to/file/MySpecialFile.pas) (revision 86251)
+++ MySpecialFile.pas (.../path/to/file/MySpecialFile.pas) (revision 83226)
@@ -140,11 +140,11 @@

So the file is marked as modified in r86212, but when I tell it to diff from HEAD to PREV, it compares r86251 to r83226.

Any idea what is causing this and how to prevent it in the future? It does not cause any problems from a technical perspective, but each time it happens I am asked to review the SVN logs to ensure there are no unintended changes making it into the code base.

EDIT: I also noticed that the file appears in gray when looking at the TortoiseSVN Log screen where all other modified files are listed in blue, added files in purple, deleted files in red, etc. These relate to Settings > General > Colors, but mine are the default, and I do not have any gray. The official documentation does not list anything about overriding colors in special circumstances.

MikeS85
  • 73
  • 6
  • What kind of file is it? Text only? Could you do a binary diff against a clean checkout next time? And could you also compare the hash against the hast of a clean checkout? And also: What the output of just `svn diff` on the root of your working copy? – Yeti May 22 '18 at 21:20
  • @Yeti: Yes, it is a text only file. With it recognized by SVN as such, I don't know how I would force a "binary diff". However, I did run `certutil -hashfile MySpecialFile.pas` against both revisions of the file, and they came back identical. As for doing a diff on the checkout, I don't have access to the one that was used to commit the revision. – MikeS85 May 23 '18 at 20:59
  • By "binary diff" I meant a tool which compares byte by byte and does not interpret the characters. But changes are low, that you have differences if you have identical hashes. – Yeti May 24 '18 at 10:42

2 Answers2

1

Despite the fact that running svn proplist MySpecialFile.pas did not return anything, and running svn propget svn:mergeinfo MySpecialFile.pas gave me this:

svn: warning: W200017: Property 'svn:mergeinfo' not found on MySpecialFile.pas

it turns out that it was the svn:mergeinfo property that changed on the file. I was able to see the property finally by selecting the revision in the TortoiseSVN log, and then right-clicking on the file and selecting "Show properties". Based on the answer here, I should be able to just delete the property from all files and subfolders.

MikeS85
  • 73
  • 6
0

Given you already ruled out most of the possibilities, there is only one scenario I can think of, which I believed happened to us before: 

svn property: svn:mime-type

If a file has this property on it clarify it's a different type other than plain text. This makes svn unable to simply store the diff on your commit, it might consider it has been changed and send it to the repo every time to store it as an individual binary file for each revision. However when come to the comparison tool it's smart enough to understand it is actually a plain text file to show you the diff screen, however given no actual changes it tells you no changes which further confuse you.

Please do let me know if that's the case or not, it's very interesting and I'm curious to know why it happened.

Simon Wang
  • 2,843
  • 1
  • 16
  • 32
  • But wouldn't the property change be visible in `svn diff`? – Yeti May 24 '18 at 10:41
  • @Yeti I would think so. – MikeS85 May 24 '18 at 13:44
  • @SimonWang I did a `svn proplist` on the file, and there was no output, so I don't think this is it. – MikeS85 May 24 '18 at 13:47
  • Yes change on property would be visible in diff, but the case I saw was that it's already there and svn treat the file diffrently hence push it as binary file, well anyway MikeS85 already ruled that out, so interesting – Simon Wang May 24 '18 at 20:16