On Thu, Aug 25, 2016 at 11:13 AM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
> On 25 August 2016 at 11:50, Vacelet, Manuel <manuel.vacelet_at_enalean.com>
> wrote:
> > On Wed, Aug 24, 2016 at 5:46 PM, Vacelet, Manuel
> > <manuel.vacelet_at_enalean.com> wrote:
> >>
> >> oops I hit shift+enter :/
> >> see my message below
> >>
> >> On Wed, Aug 24, 2016 at 5:44 PM, Vacelet, Manuel
> >> <manuel.vacelet_at_enalean.com> wrote:
> >>>
> >>> Hi all,
> >>>
> >>> I got a machine that was bumped from 1.6.x (centos6 default) to 1.8.16
> >>> (thanks wandisco!).
> >>> I identified a change of behaviour but failed to find an explanation in
> >>> book or change log.
> >>>
> >>> Here we go, given a SVNAccessFile like:
> >>
> >>
> >> ------------->8-------------
> >> [groups]
> >> members = alice
> >> admin = bob
> >>
> >> [/]
> >> * =
> >> @members = r
> >> @admin = rw
> >>
> >> [/tags]
> >> @members = rw
> >> -------------8<-------------
> >>
> >> WIth svn 1.6, as alice, I cannot rm /tags
> >> Whereas with svn 1.8 I now can.
> >>
> >> Is this detailed somewhere ?
> >
> >
> > Fun fact: the behaviour change also depending on the version of svn
> client
> > used.
> > For a given svn 1.8 server, I can delete /tags with svn 1.7, 1.8 & svn
> 1.9
> > client but not with svn 1.6.
> > I failed to find in 1.7 release note something that explains this change.
> >
> It was bug in Subversion 1.7 that remove operation requires access to
> repository root:
> SVN-4219: svn delete fails with "403 Forbidden" if root is not readable [1]
>
> This problem was fixed in Subversion 1.8. It's not server-side change.
> It was client problem accessing repository root, while it's not
> needed.
>
> [1] https://issues.apache.org/jira/browse/SVN-4219
>
>
Thanks for your reply, but according to my tests, the behaviour is
consistent with clients >1.7:
server 1.8:
* client 1.6: cannot rm
* client >1.7: can rm
server 1.6:
* client >1.6: cannot rm
Moreove, alice does have access to root in this case (but only in read).
Received on 2016-08-25 11:19:50 CEST