On May 29, 2009, at 8:27 AM, C. Michael Pilato wrote:
> Folks, we made a pretty serious regression in Subversion 1.5
> regarding the
> way our copy and move operations drive the commit editor. The
> result is
> that operations previously permitted via a particular authz policy
> no longer
> do. As a result, there are people still running 1.4 simply because
> they
> can't use 1.5. That's really bad, because 1.4 has dropped from
> official
> non-emergency support already. This is tracked in issue #3242 [1],
> and that
> issue is started to heat up.
>
> I see three courses of action:
>
> * Continue to ignore the issue. This comes with all the
> disadvantages
> you might assume from such a user-unfriendly approach.
>
> * Rewrite Subversion's authz framework, perhaps in the way I've
> recommended in issue #3380 [2]. This is very non-trivial amount
> of work though, and not backportable to existing release streams.
>
> * Fix the copy and move code to be more conservative in their
> approach. I took a stab at this a while ago, and got completely
> lost in the logic. My guess is that Hyrum is the only person who
> really has the big picture in his head there. But as a stopgap,
> I wonder if we couldn't just resurrect the 1.4 logic (as a sibling
> to the 1.5 stuff), and make the APIs fork immediately: doing a
> single-source copy or move? Use the old logic (plus some merge
> tracking handling). Else, use the new, multi-source-supporting
> stuff.
>
> I'm a bit concerned about our relationship with our user base, and
> not just
> saying that to be dramatic. What do you guys think? Is there
> anyone with
> the time and a degree of focus who can get us out of this?
>
> [1] http://subversion.tigris.org/issues/show_bug.cgi?id=3242
> [2] http://subversion.tigris.org/issues/show_bug.cgi?id=3380
I've said it before, but #3242 is mea maxima culpa from my early days
of Subversion development. It does seem to be heating up, and I think
that we should fix the bug, and then cut a (final?) 1.5.x release with
that fix.
It's been a while since I've looked at the code, but this is my
(possibly outdated) analysis of #3242:
Users are encountering the bug when trying to do something like
$ svn -m version cp https://example.com/svn/ProjectName/2008/trunk \
-r56318 https://example.com/svn/ProjectName/2008/tags/8.11.07
which results in
svn: Server sent unexpected return value (403 Forbidden) in
response to PROPFIND
request for '/svn'
In order to minimize ra accesses, the code looks for the common parent
of the source and the destination, reparents the ra_session to that
location, and then proceeds to act using at that the operational
root. The problem arises when that common root isn't accessible (due
to authz restrictions), so the copy or move errors out. I *think* the
solution is something along the lines of "be more intelligent about
reparenting the ra_session" up to and including "don't reparent".
That's a first-order approximation of what the solution could be.
This bug *is* on my list of stuff to get to eventually, but I'd be
thrilled if somebody else wanted to take a look at it. I think the
first step to fix the bug is to create a test for it, so the bug is
well-scoped. Creating a test may also help in understanding potential
solutions. Any volunteers?
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2356783
Received on 2009-05-29 16:01:32 CEST