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

Re: Subversion Issue 3242

From: Hyrum K. Wright <hyrum_at_hyrumwright.org>
Date: Fri, 31 Jul 2009 08:13:31 -0500

On Jul 31, 2009, at 7:59 AM, Stefan Sperling wrote:

> On Fri, Jul 31, 2009 at 09:09:49AM +0200, Thomas Braun wrote:
>> Hello,
>> we are using subversion 1.4.6 in our company and we need to upgrade
>> to
>> subversion 1.5.6.
>> On our test installation we are suffering from the bug mentioned in
>> issue 3242.
>> There are only few projects where somebody really has read or write
>> access on root.
>> Is there any way that this bug can be fixed in 1.5.6 ?
> As far as I know, no one is looking at this bug right now.
> I know that this is unfortunate for authz users using a default-deny
> policy.
> The problem with issue #3242 is that it is really a design bug rather
> than a simple coding error. Because of this, it is not trivial to fix
> the problem, and somebody will have to invest time to rewrite parts
> of the authz framework or try to implement other workarounds.
> This could take a couple of weeks, even with full-time work.
> Several developers have already taken a shot at possible workarounds.
> While doing so, they uncovered the underlying design issue which has
> so far prevented the workarounds from working.
> At least that is my understanding of the situation.

Is there a succinct description of the underlying problem somewhere?
I seem to recall CMike saying something about it a while ago, but I
don't know if that's true. If somebody were to step up to do this (as
you suggest below) where would the problem description be? (All of
this could be in the issue tracker, which I have not yet thoroughly
perused.) We're more likely to get developer contributions if we can
show a complete description of the design problem, and possibly some
hints as to how to proceed in fixing it.

> Given this, I'd say the best way to make sure we get a fix for this
> quickly
> is by providing additional developer resources which focus solely on
> this
> problem. I see two ways to do this.
> One way is providing help if you have capable developers in-house.
> More contributors are always welcome, and an active and healthy
> relationship
> to Subversion's developer community can be beneficial in the long-run
> for any business, especially if you use Subversion yourself, but also
> from e.g. a marketing perspective. Don't dismiss the benefits of
> direct
> involvement in the development process. Oh, and you also get #3242
> fixed.
> The other way is to offer to fund an existing developer who can't
> otherwise afford to pick up a task as big as #3242 due to lack of
> time.
> That might convince someone already familiar with the code base to
> work
> on this. Since a number of users are affected by this, and most of
> them
> seem to be corporate users, funding could probably be pooled with some
> coordination between affected parties. The Subversion Corporation
> (http://www.subversion.org) would be the appropriate contact at our
> end.

Actually, depending on the circumstance, it may be easier just to fund
a developer directly, rather than through the Corp. (We've never done
this before, and I hate to think of the accounting headaches it would
cause CMike.)


Received on 2009-07-31 15:14:16 CEST

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