Hyrum K Wright wrote on Thu, Feb 09, 2012 at 13:16:13 -0600:
> On Thu, Feb 9, 2012 at 1:05 PM, Daniel Shahaf <danielsh_at_elego.de> wrote:
> > Hyrum K Wright wrote on Thu, Feb 09, 2012 at 12:54:50 -0600:
> >> (I'll also note that we actually *do* have a checksum by this point,
> >> only it is the md5 provided by close_file(), and Ev2 uses sha1s
> >> exclusively, so we have to recalculate. I suspect this will be a
> >
> > Only sha1? It allows neither md5 nor sha256? Why?
>
> "Convention" would be my initial response. It makes much more sense
> to standardize checksum kinds across the system than to have a mixed
> environment. Any checksum can help detect corruption, but being able
> to answer the question "is this content the same as that content?" is
> much more difficult in a mixed-checksum environment. sha1 felt like a
It's hardly impossible. It shouldn't take much effort to whip up an
SQLite table that maps sha1's to sha3's (both in the wc layer and the FS
layer).
> reasonable choice[1].
>
> I could be overestimating the negatives, though. What reasons do you
> suppose we *should* allow arbitrary checksum types?
>
I didn't say "arbitrary"; but hard-wiring a specific checksum algorithm
into our APIs seems wrong. Suppose Ev2 is in 1.8 and then 1.9 clients
want to use sha4 with 1.9 servers. Does the editor interface allow for
that?
I'm assuming we could mandate sha1 support but allow driver/receiver to
negotiate on using a different algorithm.
> -Hyrum
>
> [1] Though, given the timeline of Ev2 and the proposed timeline for
> sha3, I'm really interested in the possibility of using sha3 when
> standardized, throughout *all* of Subversion. (But that's a
> completely separate discussion.)
>
>
> --
>
> uberSVN: Apache Subversion Made Easy
> http://www.uberSVN.com/
Received on 2012-02-09 20:31:27 CET