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

Re: svn and "mostly-binary" repositories

From: Michael Wood <mwood_at_its.uct.ac.za>
Date: 2001-10-01 16:03:45 CEST

On Mon, Oct 01, 2001 at 08:25:33AM -0400, Greg Hudson wrote:
> > - Efficient file transfer protocols. Using rsync might be of
> > interest.
>
> I'm not sure how rsync would fit. We are definitely much more
> sparing with bytes on the wire than CVS is, though; we always
> send diffs where possible, never the complete text of files.
>
> > - Efficient file comparison. When deciding wether a local
> > file is in sync with the repository, use md5sum instead of
> > fetching and diffing.
>
> What we do at the moment is store a pristine copy of each
> working copy file in the admin directory. This allows us to
> send diffs across the wire for commits, and to determine
> whether a file has been modified by looking at mod times and
> performing a local diff if they're different. Unfortunately,
> it also comes at a 100% space penalty in the working copy; a
> checkout of a 1GB source directory will come in at 2GB.
>
> In theory, we will make it an option in some post-1.0 release
> to omit the pristine copy in the working copy, and instead use
> hash checksums of some kind to decide whether a local file is
> in sync with the repository. And, of course, to do a commit
> the client would have to send the new complete text rather
> than send a diff.
[snip]

As I understand it, rsync works basically like so:

The server and the client both chop the file into blocks. They
both then compute checksums of all the blocks. One then sends
its list of block checksums to the other. Then the blocks that
are different are transferred.

i.e. it's more efficient than just transferring the whole file,
and you don't need to keep a copy of the original to see what's
changed.

Btw, there's a librsync that might be useful for subversion.

-- 
Michael Wood
<mwood@its.uct.ac.za>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:43 2006

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.