On 09.06.2015 21:31, Philip Martin wrote:
> Philip Martin <philip.martin_at_wandisco.com> 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
Received on 2015-06-09 21:49:54 CEST