Evgeny Kotkov <evgeny.kot...@visualsvn.com> wrote: > 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.
I think you misunderstand what the problem was with the old 'blame -g' code. We should look up the actual code and As far as I recall, the interesting 'blame -g' case concerns a comparison between files 'trunk/foo' and 'branch1/foo': it is common for those files to have the same content, while the old 'blame -g' code relied on the comparison always reporting a 'difference' in such a case even when they have the same content. This is not a case where "committing a no-op change" ever happened to the file. > '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.) > ]]] If you will notice, C-Mike didn't address the difference between a "change" in a linear sequence of commits and a "change" across two [arbitrary] points in its history. While the meaning of the former is straightforward, the latter is not, as I discussed in my separate post. In fact, the idea that there is a "change" across two arbitrary points in history is degenerative, in that after two versions of file "foo" have been created (trunk/foo and branch1/foo) and a "change" is reported when comparing them, there is no way in Subversion to commit a new state such that no "change" is reported. So I understand C-Mike's quote as applying only to the case where svn_fs_contents_changed() is given two points along the history of a given file or directory. The case where it is given two arbitrary points in history (such as trunk/foo and branch1/foo) is, so far, neither defined nor justified. Do you think there is a way in which reporting a "change" as the result of comparing two arbitrary points in history can be useful? If so, can you explain what and how? - Julian > 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
