On Fri, Sep 25, 2015 at 8:01 PM, Julian Foad <[email protected]> wrote:
> (New thread, taken from an observation in the "No-op changes no longer > dumped..." thread. In that thread, I hadn't spotted that it is only > the props comparison.) > > Starting from 1.9.0, the FS API content comparison methods > > svn_fs_contents_changed() > svn_fs_contents_different() > svn_fs_props_changed() > svn_fs_props_different() > > are implemented in FSFS by svn_fs_fs__dag_things_different() which calls > > svn_fs_fs__prop_rep_equal(strict=TRUE/FALSE) > and/or > svn_fs_fs__file_text_rep_equal(strict=TRUE/FALSE) > > * svn_fs_fs__file_text_rep_equal() uses MD5 checksum as a quick check, > returns 'not equal' if MD5s do not match, else gets a definitive > answer by comparing SHA1s (if present) or full text [1]. That's fine. > > * svn_fs_fs__prop_rep_equal(), by contrast, reports that two > properties-reps are equal if their MD5 checksums are equal. [2] > I think we should simply do the same level of checking as for the file contents. To even trigger the to-be-added check, two conditions must be met: * The prop representation must not be the same. * The prop contents must be the same (at least same MD5). With rep sharing enabled, this combination will virtually never occur. Furthermore, we call this function for only for nodes that share some common history. But along the same line of history, this requires changing the props back & forth - which is arguably a rare case. So, this leaves us with switching between branches where e.g. a property change got merged between them. Because it is unusual to only touch the props of a node on some branch and then merge that change, we can assume that the full prop comparison is relatively cheap compared to the file content update. IOW, it is hard to construct a case where performing a full prop comparison would add relevant overhead. -- Stefan^2.
