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

Re: svn commit: r21289 - in trunk: build/ac-macros subversion/libsvn_ra_dav

From: Daniel Rall <dlr_at_collab.net>
Date: 2006-09-06 23:02:27 CEST

On Wed, 06 Sep 2006, Max Bowsher wrote:

> Daniel Rall wrote:
> > On Mon, 28 Aug 2006, Malcolm Rowe wrote:
> >
> >> On Mon, Aug 28, 2006 at 01:04:55PM +0100, Max Bowsher wrote:
> >>> Speaking of which, isn't a list rather the wrong approach to take here?
> >>>
> >>> Shouldn't we accept:
> >>> * any 0.24.x where x >= 7
> >>> * any 0.25.x
> >>> * any 0.26.x
> >>> ?
> >>>
> >> Yes, in theory. I think that, historically, Neon hasn't been exactly
> >> stable over the sub-minor versions, and so the current 'approve known-good
> >> versions' approach evolved from that. I don't know whether that approach
> >> is still necessary.
> >
> > That's why we have the explicit "allow list" in the first place.
> > Given the number of problems seen with Neon Windows auth, I tend to
> > think we should stick with this approach.
>
> I'm mainly looking to avoid a situation where neon 0.26.2 gets released,
> and people have to use --disable-neon-version-check until we get a patch
> release of Subversion out that validates it.
>
> That just seems overly messy. It would be bad for people to habituate to
> using --disable-neon-version-check as a matter of course.

I agree that that is a maintenance burden. But is it worse than a
deluge of bug reports from an unverified, incompatible/buggy version
of Neon? In the past, we thought so. But perhaps as Neon matures,
that's no longer as much a need for worry? (I hope so.)

- Dan

  • application/pgp-signature attachment: stored
Received on Wed Sep 6 23:29:05 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.