On Thu, Aug 25, 2016 at 11:29 AM, Ivan Zhakov <i...@visualsvn.com> wrote:
> On 25 August 2016 at 12:19, Vacelet, Manuel <manuel.vace...@enalean.com> > wrote: > > 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). > > > You are right. The issue was fixed in Subversion 1.7.9 > https://issues.apache.org/jira/browse/SVN-4332 > > Ivan, I don't think it the same issue as in my case, the users always have access to repository root. Moreover I don't have a consistent behaviour with clients that are newer than 1.7.9 (tested with clients 1.8 & 1.9). I don't know if it's a bug, actually my issue is: - What is the expected behaviour (what are the rights needed to delete a folder, write on the folder or write on its parent) ? - Why this behaviour changed between 1.6 and newer ? Manuel
