You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Malcolm Rowe <ma...@farside.org.uk> on 2006/08/28 11:34:44 UTC
Re: svn commit: r21289 - in trunk: build/ac-macros subversion/libsvn_ra_dav
On Mon, Aug 28, 2006 at 03:35:12AM -0700, maxb@tigris.org wrote:
> Neon 0.26.x compatibility, at least for the Unix build.
>
You didn't add 0.26.[01] to NEON_ALLOWED_LIST. Is there still some work
that needs to be done to get it to work properly?
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r21289 - in trunk: build/ac-macros subversion/libsvn_ra_dav
Posted by Daniel Rall <dl...@collab.net>.
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
Re: svn commit: r21289 - in trunk: build/ac-macros subversion/libsvn_ra_dav
Posted by Max Bowsher <ma...@ukf.net>.
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.
Max.
Re: svn commit: r21289 - in trunk: build/ac-macros subversion/libsvn_ra_dav
Posted by Daniel Rall <dl...@collab.net>.
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.
Re: svn commit: r21289 - in trunk: build/ac-macros subversion/libsvn_ra_dav
Posted by Malcolm Rowe <ma...@farside.org.uk>.
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.
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r21289 - in trunk: build/ac-macros subversion/libsvn_ra_dav
Posted by Max Bowsher <ma...@ukf.net>.
Malcolm Rowe wrote:
> On Mon, Aug 28, 2006 at 03:35:12AM -0700, maxb@tigris.org wrote:
>> Neon 0.26.x compatibility, at least for the Unix build.
>>
>
> You didn't add 0.26.[01] to NEON_ALLOWED_LIST. Is there still some work
> that needs to be done to get it to work properly?
Umm, oops. I've become so accustomed to --disable-neon-version-check
that I'd forgotten entirely about the NEON_ALLOWED_LIST.
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
?
Max.