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

Re: [PROPOSAL] Addition of rsync algorithm for saving bandwidth in 'svn takeover'

From: Jonathan Gilbert <o2w9gs702_at_sneakemail.com>
Date: 2005-07-13 06:32:49 CEST

At 03:37 AM 13/07/2005 +0200, =?UTF-8?B?QnJhbmtvIMSMaWJlag==?=
brane-at-xbc.nu |subversion de wrote:
>Jonathan Gilbert wrote:
>>The way I see it, the rsync code itself is a relatively small part of the
>>patch which adds this operation with client->server checksum sending
>>action. It would only mean a hundred lines of code or so to include or not
>>include block-oriented rsync.
>I don't believe that. Sure, the difference between producing one
>checksum for a file and producing several is negligible, but changing
>the checkout/update logic to send only the differing chunks of the file
>is not a simple change,

That all depends on how you design the added functionality. I was never
considering modifying existing code paths directly. My plan is to create a
separate library, libsvn_rsync, within which all of the work is done. A
structure called svn_rsync_channel_t wraps up the underlying libsvn_ra
session(s) and provides for the necessary data transfer.

>>The other thing is, you may not feel ready to take my word for this, but if
>>I contribute a large block of code like this, I automatically ensure that I
>>will be around to maintain it, should problems arise.
>"The project" has to maintain the code indefinitely. We can't assume
>that a certaini individual will always be available to maintain a
>particular piece of code. That's why we insist on a uniform coding
>style, checkin comment format and documentation in the code.

This is fair enough. I cannot foresee the time when I become completely
unable to provide maintenance for the code, but it would be foolish to deny
that this will eventually happen. I am, of course, following the standard
coding style as closely as I can discern, and any discrepencies will be
brought into line if/when code is presented to the list for review by
programmers more accustomed to SVN's style than I.

Jonathan Gilbert

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 13 06:35:00 2005

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.