[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: No-op changes no longer dumped by 'svnadmin dump' in 1.9

From: Evgeny Kotkov <evgeny.kotkov_at_visualsvn.com>
Date: Tue, 27 Oct 2015 16:38:02 +0300

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 [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

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

Evgeny Kotkov
Received on 2015-10-27 14:38:38 CET

This is an archived mail posted to the Subversion Dev mailing list.