On Thu, Aug 25, 2016 at 11:13 AM, Ivan Zhakov <i...@visualsvn.com> wrote:
> On 25 August 2016 at 11:50, Vacelet, Manuel <manuel.vace...@enalean.com> > wrote: > > On Wed, Aug 24, 2016 at 5:46 PM, Vacelet, Manuel > > <manuel.vace...@enalean.com> wrote: > >> > >> oops I hit shift+enter :/ > >> see my message below > >> > >> On Wed, Aug 24, 2016 at 5:44 PM, Vacelet, Manuel > >> <manuel.vace...@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).
