At 01:01 PM 12/07/2005 -0500, Sussman wrote:
>On Jul 12, 2005, at 12:50 PM, Ben Collins-Sussman wrote:
>> The problem is that we're no longer KISS. Adding rsync-like code
>> has a cost: we have to maintain it, debug it, and support it
>> forever more. And I don't think the problem it's solving is
>> actually a problem we need to care about. The benefit is negligible.
>
>Hm, sorry for the verbosity. Let me sum up in one sentence:
>
>"Your unadorned patch prevents people from re-downlading 95% of their
>project; it's not worth adding rsync-complexity to prevent users from
>re-downloading an additional 3%."
The problem is that the unadorned patch does NOT prevent downloading. In
order to prevent downloading, even at the file level, new functionality
must be added. In fact, the behaviour of a file-based synchronization would
be fundamentally the same as the rsync-type block-based synchronization.
Instead of blocks, it would be checksumming entire files, but it would
still need the same steps and pipelining, of sending the checksums to the
server and then getting the server's response, in the form of an "edit
script" that builds an entire WC by copying flies instead of an individual
file by copying blocks. The latter half of this is what 'svn update' does
right now.
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.
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.
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 01:08:16 2005