On 09.06.2015 21:31, Philip Martin wrote: > Philip Martin <[email protected]> writes: > >> The 1.9 server is sending the same revisions as the 1.8 server but some >> of the revisions from the 1.9 server do not have a textdelta. Both the >> 1.8 and 1.9 servers call svn_repos_get_file_revs2() which calls >> send_path_revision(). Inside send_path_revision() the 1.8 server uses >> svn_fs_contents_changed() to determine if there is a textdelta while 1.9 >> uses svn_fs_contents_different(). svn_fs_contents_different() does not >> exist in 1.8 but is related to svn_fs_contents_changed() via the strict >> flag. It seems the strict flag is supposed to make this work but it >> doesn't appear to work in this case. > There was discussion at the time of the change: > > http://svn.haxx.se/dev/archive-2014-02/0165.shtml > http://svn.haxx.se/dev/archive-2014-02/0324.shtml > http://svn.haxx.se/dev/archive-2014-03/0000.shtml > > 1.9 has a more accurate svn_fs_contents_changed() that doesn't report as > many false positives. This means that some (or all?) of the -g revisions > reported by svn_repos_get_file_revs2() do not include a textdelta that > was included by 1.8. It appears at some level the 1.9 client interprets > the revision without a textdelta as being the same as a revision with a > textdelta that changes nothing, while the 1.8 client relies on the > missing textdelta. If I force the 1.9 server to send textdeltas between > identical texts the 1.8 client then behaves as the test expects.
I think there's no doubt that the 1.9 server has to send no-op deltas the same way the 1.8 server did. Changing an API should not affect server behaviour as seen by the clients. We could optionally add a capability so that 1.9 clients can tell the server not to send the unnecessary deltas. This would make sense only if calculating the deltas is expensive. -- Brane
