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

[Daniel Shahaf <d....@daniel.shahaf.name>]

Justin Erenkrantz wrote on Sat, Dec 01, 2012 at 09:50:29 -0500:
> On Sat, Dec 1, 2012 at 9:41 AM, Branko Čibej <br...@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
> yourself!

If that's the problem, have the server send the recorded-in-fs sha1
checksum as an attribute that the client ignores. (in SVN_DEBUG builds
only)

> 
> 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