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.
'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 :
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
In 1.9 we changed how svn_fs_contents_changed() works, added an errata,
claimed that all of these distinctions are "false positives" , 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.
Received on 2015-10-27 14:38:38 CET