Evgeny Kotkov <evgeny.kotkov_at_visualsvn.com> wrote:
> Bert Huijben <bert_at_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
Received on 2015-10-27 15:31:40 CET