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

Re: svn commit: r1640832 - /subversion/trunk/subversion/libsvn_delta/text_delta.c

From: Branko Čibej <brane_at_wandisco.com>
Date: Fri, 21 Nov 2014 13:11:26 +0100

On 21.11.2014 11:53, Philip Martin wrote:
> philip_at_apache.org writes:
>
>> Author: philip
>> Date: Thu Nov 20 22:36:27 2014
>> New Revision: 1640832
>>
>> URL: http://svn.apache.org/r1640832
>> Log:
>> Followup to r1618841, the old fast_memcpy() returned target+len but
>> the replacement memcpy() returns target.
>>
>> * subversion/libsvn_delta/text_delta.c
>> (patterning_copy): Adjust target after memcpy.
> This bug caused checksum failures when reading a BDB repository. As far
> as I can tell it only affects the BDB code (the delta combiner used in
> the BDB code is the only place that generates svn_txdelta_target) and
> this code is not exercised by the test suite.
>
> I don't understand the patterns that cause the repository to contain
> svn_txdelta_target so I can't easily write a testcase.

The combiner only produces target copies if the source delta(s) contain
them. We shouldn't be generating any since we started using the xdelta
algorithm instead of vdelta; I don't really understand why BDB would be
using vdelta instead, not even for compatibility reasons.

In any case, your fix is correct.

-- Brane

P.S.: The presence of target copies in deltas could, in certain
not-so-rare cases with overlapping target copies, make the delta
combiner grind to a halt. The combiner algorithm could suddenly have a
fourth-order dependency on the number of instructions, which would blow
the CPU for the actual delta application sky-high. That's why dberlin
replaced vdelta with xdelta, way back when.
Received on 2014-11-21 13:12:08 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.