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

Re: svn commit: r1415864 - /subversion/trunk/subversion/libsvn_ra_serf/update.c

From: Justin Erenkrantz <justin_at_erenkrantz.com>
Date: Sat, 1 Dec 2012 09:50:29 -0500

On Sat, Dec 1, 2012 at 9:41 AM, Branko Čibej <brane_at_wandisco.com> wrote:

> On 01.12.2012 14:31, Justin Erenkrantz wrote:
> > And, yes, that clearly could all be done in time for 1.8 without
> > jeopardizing the timelines one tiny bit. =P
> Eep ... :)
> Another thing I've been thinking about is this: Why are we using SHA1
> checksums on the server and on the wire for consistency checks when a
> 64-bit CRC would do the job just as well, and 15 times cheaper? And
> banging my head against the wall for not thinking of this 10 years ago.
> I can sort of understand the use of SHA1 as a content index for
> client-side pristine files. On the server, however ... dunno. Maybe we
> could design something akin to what the rsync protocol does, but for
> repository-wide data storage. Could be quite tricky to achieve locality,
> however.

The one thing that's nice with using SHA checksums is we're using it
everywhere. It makes protocol debugging a *lot* easier - since we also
used SHA checksums as the content index, that makes it easier to compare
what we recorded in libsvn_wc to what was sent by the server. If we
diverged the checksums algorithms, it'd be hard to do a quick comparison
visually (do the checksums match?) without actually running the checksum

So, I think we optimized for humans here...and I'm okay with that. We can
always build faster processors...and take advantage of parallelism. =)

There I go off on a tangent again.

*grin* -- justin
Received on 2012-12-01 15:51:02 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.