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

Re: Why do we check the base checksum so often?

From: Daniel Shahaf <danielsh_at_elego.de>
Date: Tue, 7 Feb 2012 01:15:36 +0200

I get your distinction between "clients that use the native Ev2 API",
"clients that use the Ev1 API in Ev2-aware libraries", and "clients that
use the Ev1 API in Ev2-oblivious libraries".

But I think striking the word(s) "third-party" from your third paragraph
will not affect its correctness.

Greg Stein wrote on Mon, Feb 06, 2012 at 17:55:29 -0500:
> On Mon, Feb 6, 2012 at 17:39, Daniel Shahaf <danielsh_at_elego.de> wrote:
> >...
> > 1. Third-parties who use Ev1 interface would lose the integrity check.
> >
> > 2. Subversion 1.7 uses, and will use, Ev1 interfaces.
> >
> > Therefore:
> >
> > 3. Subversion 1.7 would lose the integrity check.
> >
> > Correct?
> Nope. 'svn' is not considered a third-party, to begin with. Further,
> internally, it only uses the Ev1 interfaces. No shims get inserted.
> When we deploy Ev2 within the svn libraries and tools (in the 1.8 or
> 1.9 release), we aren't going to use the shims, so we aren't going to
> lose the integrity check.
> Third party clients, linked to Ev2-using libraries, and which continue
> to use the old Ev1 APIs will have a shim inserted, and (thus) lose the
> base_checksum integrity check.
> IOW, when we release an Ev2-based Subversion, and third-party clients
> that were built against the 1.0 through 1.7 APIs... those clients will
> have shims inserted, and lose the check. It *is* possible that our
> backwards-compat code could fetch the checksum and pass it along to
> those third-party Ev1 users. But in the current dual-shim setup that
> Hyrum is developing/testing with, there is no such mechanism for
> fetching (hard to do, compared to just disabling the check in the
> first place).
> Does that make sense?
> Cheers,
> -g
Received on 2012-02-07 00:16:23 CET

This is an archived mail posted to the Subversion Dev mailing list.