Bert Huijben <b...@qqmail.nl> writes: > But this 'go back to 1.8' suggestio changes Subversion everywhere. It will > make 'svn annotate' slower... Makes 'svn update' slower and report more tree > conflicts, etc. etc.
For 'svn blame', the only difference is that we would be processing no-op changes in file history, and I don't think that it would have a noticeable impact on the speed because no-op changes aren't the common case. 'svn update' isn't going to be slower as well, and isn't going to produce more tree conflicts. The reporter does not send empty deltas since 1.8 — see r1442555 and the related discussion in [1, 2]. > We never designed the old behavior; we just used the functions that were > there. If we want it back we should document it, probably add regression > tests... and determine in which places we want it. I have to disagree. >From what I see, the original design of svn_fs_contents_changed() and its calling sites had all these cases in mind. Even more, it was done that way to support them. Quoting C. Michael Pilato from the already mentioned thread [3]: [[[ svn_fs_contents_changed() was not designed to be used to detect when two files have different content, but really to detect when the contents of a given file have changed across two points in its history. For the purposes of preserving accurate history, certain bits of code (such as the repos dump code) needs to care about this distinction. For example, it's not an error from the FS API point of view to call svn_fs_apply_textdelta() and explicitly set a file's contents to exactly what they were before you made the edit. But we try to preserve that fact when dumping rather than claim that the file didn't change at all (despite there being a change of modified parent directories and an associated `changes' table entry which claim otherwise.) ]]] In 1.9 we changed how svn_fs_contents_changed() works, added an errata, claimed that all of these distinctions are "false positives" [4], and switched all the calling sites to the new API that doesn't care about them. As one visible consequence, we no longer dump the changes that the original API was designed to preserve. And there could be more. [1] https://svn.apache.org/r1442555 [2] http://svn.haxx.se/dev/archive-2013-01/0439.shtml [3] http://svn.haxx.se/dev/archive-2013-02/0002.shtml [4] https://subversion.apache.org/docs/api/latest/group__fs__handling.html#gaede66ee7850d389bcdeb5ddef1540fdc Regards, Evgeny Kotkov
