svn commit: r1633232 - /subversion/trunk/subversion/libsvn_fs_fs/fs_fs.c

[st...@apache.org]

Author: stefan2
Date: Mon Oct 20 21:29:27 2014
New Revision: 1633232

URL: http://svn.apache.org/r1633232
Log:
Fix edge case in the svn_fs_contents_changed for file nodes with matching
MD5 but different contents in FSFS.  If the nodes have different IDs and
the SHA1s are not known (pre-1.6 format revision), always default to
"different".  This is then identical with the pre-1.9 behavior.

The other backends are not affected.

* subversion/libsvn_fs_fs/fs_fs.c
  (svn_fs_fs__file_text_rep_equal): We must report false negative *equals*
                                    instead of false positive ones.

Found by: julianfoad

Modified:
    subversion/trunk/subversion/libsvn_fs_fs/fs_fs.c

Modified: subversion/trunk/subversion/libsvn_fs_fs/fs_fs.c
URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_fs_fs/fs_fs.c?rev=1633232&r1=1633231&r2=1633232&view=diff
==============================================================================
--- subversion/trunk/subversion/libsvn_fs_fs/fs_fs.c (original)
+++ subversion/trunk/subversion/libsvn_fs_fs/fs_fs.c Mon Oct 20 21:29:27 2014
@@ -1471,10 +1471,15 @@ svn_fs_fs__file_text_rep_equal(svn_boole
     }
 
   /* Old repositories may not have the SHA1 checksum handy.
-     This check becomes expensive.  Skip it unless explicitly required. */
+     This check becomes expensive.  Skip it unless explicitly required.
+
+     We already have seen that the ID is different, so produce a likely
+     false negative as allowed by the API description - even though the
+     MD5 matched, there is an extremely slim chance that the SHA1 wouldn't.
+   */
   if (!strict)
     {
-      *equal = TRUE;
+      *equal = FALSE;
       return SVN_NO_ERROR;
     }