Moretti, Giovanni wrote:
>I had thought because of the following:
>
>============================================================
># Client/server protocol sends diffs in both directions
>
>The network protocol uses bandwidth efficiently by
>transmitting diffs in both directions whenever possible
>(CVS sends diffs from server to client, but not client
>to server).
>============================================================
>and from the SVN Book:
>
>"Also, the cached pristine files allow the Subversion client
> to send differences when committing, which CVS cannot do."
>============================================================
>
>that modifying a large powerpoint presentation (20MB) would not send the
>whole file but just a patch-file.
>
>
Yes, that's what happens, but the format is not a patch (i.e., not the
output of "svn diff"), but a binary delta.
>This doesn't seem to be the case - commits take ages - many minutes over
>an ADSL line.
>
>
But the amount of data sent over the network isn't the only thing that
affects how long a commit will last.
>After this happened I tried to generate a patch file but it evidently
>only applies to text files.
>
>
Because "svn diff" has nothing to do with what SVN sends over the network.
>There are algorithms that determine the smallest (or really small)
>change-set needed to update a remote file to make it the same as a local
>one (eg rsync ..._
>
>
Yes, Subversion uses one such algorithm.
>Is there a way of making subversion send just the minimal change-set,
>does it already do it (and my minor changes to the Powerpoint file
>somehow rewrote large chunks of the file), or have I misunderstood the
>manual as quoted above?
>
>
Subversion already does what you want.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Oct 5 09:58:44 2004