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

Re: some questions about the delta operation in SVN

From: Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com>
Date: Wed, 6 Mar 2013 22:46:39 +0100

On Wed, Mar 6, 2013 at 4:14 PM, Bo Chen <bo.irvine.chen_at_gmail.com> wrote:

> Clarify one point: The file_at_base (or the file @head) refers to the file I
> am currently updating, right?
>
> I am very curious why the server needs to re-compute the skip-delta. Is
> there any rule to guide the server which pristine version to be delta-ed
> against? To optimize the delta (specifically, to optimize the storage for
> the delta)?
>
> Thanks.
>
> Bo
>

Hi Bo,

To prevent any confusion, I want to point out that there are
two *independent* places where deltas are being applied:

(1) Between client and server.
    This is to conserve network bandwidth and is optional
    (depending on the protocol, they may simply send fulltext).
    The delta base is always the latest version that client has,
    i.e. BASE. In case of an update, the client tells the server
    what the respective BASE revision is ("I'm on rev 42 for
    sub-tree X/Y. Please send me the data for revision 59.")

    Data sent from the client to the server is *always* fully
    reconstructed from the incoming delta. This is necessary
    to calculate and verify the MD5 / SHA1 checksums. All
    of this happens "streamy", i.e. the data gets reconstructed
    and processed *while* coming in. There is no temporary
    file on the server eventually containing the full file contents.

    Data sent from the server to the client always starts as
    a fulltext read from the repository. If the client has already
    another version of that file and the protocol supports deltas,
    the server will read that other revision from the repository, too,
    and then calculate the delta while sending it streamingly to
    the client.

(2) When the server writes data to the repository, it starts of with
    some fulltext coming in and *may* choose to deltify the new
    contents against some existing contents.

    This is done to conserve disk space and results in a chain of
    deltas that *all* need to be read and combined to reconstruct
    the fulltext. As Ben already pointed out, 1.8 has a number of
    tuning knobs that allow you to shift the balance between data
    size (small deltas) and reconstruction effort (number of deltas
    to read and process for a given fulltext).

-- Stefan^2.

-- 
Certified & Supported Apache Subversion Downloads:
*
http://www.wandisco.com/subversion/download
*
Received on 2013-03-06 22:47:12 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.