On Fri, Sep 25, 2015 at 8:01 PM, Julian Foad <julianfoad_at_gmail.com> 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.
Received on 2015-09-28 10:47:46 CEST