You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Vacelet, Manuel" <ma...@enalean.com> on 2016/08/24 15:44:22 UTC
Permissions need for deletion
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:
Re: Permissions need for deletion
Posted by "Vacelet, Manuel" <ma...@enalean.com>.
On Wed, Aug 31, 2016 at 2:14 PM, Ivan Zhakov <iv...@visualsvn.com> wrote:
> On 31 August 2016 at 14:54, Vacelet, Manuel <ma...@enalean.com>
> wrote:
> > On Wed, Aug 31, 2016 at 12:37 PM, Ivan Zhakov <iv...@visualsvn.com>
> wrote:
> >>
> >> On 31 August 2016 at 13:28, Vacelet, Manuel <manuel.vacelet@enalean.com
> >
> >> wrote:
> >> > On Wed, Aug 31, 2016 at 12:19 PM, Ivan Zhakov <iv...@visualsvn.com>
> >> > wrote:
> >> >>
> >> >>
> >> >> > - Why this behaviour changed between 1.6 and newer ?
> >> >> It was bug before Subversion 1.7.9. The problem was that client tried
> >> >> to read some information from repository root when performing remove
> >> >> folder. See SVN-4332 for more details [1]
> >> >>
> >> >> [1] https://issues.apache.org/jira/browse/SVN-4332
> >> >>
> >> >
> >> > I did read that but in my tests, when server is 1.6, whatever version
> of
> >> > client (1.6, 1.7, 1.8, 1.9), cannot remove.
> >> >
> >> > When server is 1.8, behaviour change depending on client version so it
> >> > might
> >> > be related to this issue (even if in all cases, the user has access to
> >> > the
> >> > root).
> >> >
> >> It's could be related to HTTPv2 protocol introduced in Subversion 1.7.
> >> Could you provide requests log with svn server 1.6?
> >>
> >> [1] https://subversion.apache.org/docs/release-notes/1.7.html#httpv2
> >>
> >
> > Here we go, on client side, svn, version 1.9.3 (r1718519)
> >
> > Server is svn, version 1.6.11 (r934486)
> > 172.17.42.1 - - [31/Aug/2016:11:52:37 +0000] "OPTIONS
> /svntest/fakerepo/tags
> > HTTP/1.1" 401 501
> > 172.17.42.1 - alice [31/Aug/2016:11:52:37 +0000] "OPTIONS
> > /svntest/fakerepo/tags HTTP/1.1" 200 196
> > 172.17.42.1 - alice [31/Aug/2016:11:52:37 +0000] "OPTIONS
> > /svntest/fakerepo/tags HTTP/1.1" 200 97
> > 172.17.42.1 - alice [31/Aug/2016:11:52:37 +0000] "PROPFIND
> > /svntest/fakerepo/tags HTTP/1.1" 207 700
> > 172.17.42.1 - alice [31/Aug/2016:11:52:37 +0000] "PROPFIND
> > /svntest/fakerepo/tags HTTP/1.1" 207 325
> > 172.17.42.1 - alice [31/Aug/2016:11:52:40 +0000] "MKACTIVITY
> > /svntest/fakerepo/!svn/act/8267278f-ed0c-42db-a6c8-65f010a954c9
> HTTP/1.1"
> > 201 337
> > 172.17.42.1 - alice [31/Aug/2016:11:52:40 +0000] "PROPFIND
> /svntest/fakerepo
> > HTTP/1.1" 207 400
> > 172.17.42.1 - alice [31/Aug/2016:11:52:40 +0000] "CHECKOUT
> > /svntest/fakerepo/!svn/vcc/default HTTP/1.1" 201 352
> > 172.17.42.1 - alice [31/Aug/2016:11:52:40 +0000] "PROPPATCH
> > /svntest/fakerepo/!svn/wbl/8267278f-ed0c-42db-a6c8-65f010a954c9/15
> HTTP/1.1"
> > 207 469
> > 172.17.42.1 - alice [31/Aug/2016:11:52:40 +0000] "CHECKOUT
> > /svntest/fakerepo/!svn/ver/15 HTTP/1.1" 403 330
> ^^^ Here is the problem. Subversion tries to CHECKOUT (DAV HTTP
> method) parent of resource when using HTTPv1 protocol, but it should
> not. I was able to reproduce this problem locally. As far I see we
> don't have test for this case.
>
> > 172.17.42.1 - alice [31/Aug/2016:11:52:40 +0000] "DELETE
> > /svntest/fakerepo/!svn/act/8267278f-ed0c-42db-a6c8-65f010a954c9
> HTTP/1.1"
> > 204 -
> >
> > Server is svn, version 1.8.16 (r1740329):
> > 172.17.42.1 - - [31/Aug/2016:11:43:53 +0000] "OPTIONS /svntest/fakerepo
> > HTTP/1.1" 401 501
> > 172.17.42.1 - alice [31/Aug/2016:11:43:53 +0000] "OPTIONS
> /svntest/fakerepo
> > HTTP/1.1" 200 196
> > 172.17.42.1 - alice [31/Aug/2016:11:43:53 +0000] "OPTIONS
> /svntest/fakerepo
> > HTTP/1.1" 200 97
> > 172.17.42.1 - alice [31/Aug/2016:11:43:53 +0000] "POST
> > /svntest/fakerepo/!svn/me HTTP/1.1" 201 -
> > 172.17.42.1 - alice [31/Aug/2016:11:43:53 +0000] "DELETE
> > /svntest/fakerepo/!svn/txr/13-g/tags HTTP/1.1" 204 -
> > 172.17.42.1 - alice [31/Aug/2016:11:43:53 +0000] "MERGE /svntest/fakerepo
> > HTTP/1.1" 200 756
> >
> As you see Subversion perform DELETE directly, without CHECKOUT when
> using HTTPv2 protocol. That's expected behavior.
>
>
Alright, perfect :)
Thanks for the informations and the time you spent on that !
Re: Permissions need for deletion
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 31 August 2016 at 14:54, Vacelet, Manuel <ma...@enalean.com> wrote:
> On Wed, Aug 31, 2016 at 12:37 PM, Ivan Zhakov <iv...@visualsvn.com> wrote:
>>
>> On 31 August 2016 at 13:28, Vacelet, Manuel <ma...@enalean.com>
>> wrote:
>> > On Wed, Aug 31, 2016 at 12:19 PM, Ivan Zhakov <iv...@visualsvn.com>
>> > wrote:
>> >>
>> >>
>> >> > - Why this behaviour changed between 1.6 and newer ?
>> >> It was bug before Subversion 1.7.9. The problem was that client tried
>> >> to read some information from repository root when performing remove
>> >> folder. See SVN-4332 for more details [1]
>> >>
>> >> [1] https://issues.apache.org/jira/browse/SVN-4332
>> >>
>> >
>> > I did read that but in my tests, when server is 1.6, whatever version of
>> > client (1.6, 1.7, 1.8, 1.9), cannot remove.
>> >
>> > When server is 1.8, behaviour change depending on client version so it
>> > might
>> > be related to this issue (even if in all cases, the user has access to
>> > the
>> > root).
>> >
>> It's could be related to HTTPv2 protocol introduced in Subversion 1.7.
>> Could you provide requests log with svn server 1.6?
>>
>> [1] https://subversion.apache.org/docs/release-notes/1.7.html#httpv2
>>
>
> Here we go, on client side, svn, version 1.9.3 (r1718519)
>
> Server is svn, version 1.6.11 (r934486)
> 172.17.42.1 - - [31/Aug/2016:11:52:37 +0000] "OPTIONS /svntest/fakerepo/tags
> HTTP/1.1" 401 501
> 172.17.42.1 - alice [31/Aug/2016:11:52:37 +0000] "OPTIONS
> /svntest/fakerepo/tags HTTP/1.1" 200 196
> 172.17.42.1 - alice [31/Aug/2016:11:52:37 +0000] "OPTIONS
> /svntest/fakerepo/tags HTTP/1.1" 200 97
> 172.17.42.1 - alice [31/Aug/2016:11:52:37 +0000] "PROPFIND
> /svntest/fakerepo/tags HTTP/1.1" 207 700
> 172.17.42.1 - alice [31/Aug/2016:11:52:37 +0000] "PROPFIND
> /svntest/fakerepo/tags HTTP/1.1" 207 325
> 172.17.42.1 - alice [31/Aug/2016:11:52:40 +0000] "MKACTIVITY
> /svntest/fakerepo/!svn/act/8267278f-ed0c-42db-a6c8-65f010a954c9 HTTP/1.1"
> 201 337
> 172.17.42.1 - alice [31/Aug/2016:11:52:40 +0000] "PROPFIND /svntest/fakerepo
> HTTP/1.1" 207 400
> 172.17.42.1 - alice [31/Aug/2016:11:52:40 +0000] "CHECKOUT
> /svntest/fakerepo/!svn/vcc/default HTTP/1.1" 201 352
> 172.17.42.1 - alice [31/Aug/2016:11:52:40 +0000] "PROPPATCH
> /svntest/fakerepo/!svn/wbl/8267278f-ed0c-42db-a6c8-65f010a954c9/15 HTTP/1.1"
> 207 469
> 172.17.42.1 - alice [31/Aug/2016:11:52:40 +0000] "CHECKOUT
> /svntest/fakerepo/!svn/ver/15 HTTP/1.1" 403 330
^^^ Here is the problem. Subversion tries to CHECKOUT (DAV HTTP
method) parent of resource when using HTTPv1 protocol, but it should
not. I was able to reproduce this problem locally. As far I see we
don't have test for this case.
> 172.17.42.1 - alice [31/Aug/2016:11:52:40 +0000] "DELETE
> /svntest/fakerepo/!svn/act/8267278f-ed0c-42db-a6c8-65f010a954c9 HTTP/1.1"
> 204 -
>
> Server is svn, version 1.8.16 (r1740329):
> 172.17.42.1 - - [31/Aug/2016:11:43:53 +0000] "OPTIONS /svntest/fakerepo
> HTTP/1.1" 401 501
> 172.17.42.1 - alice [31/Aug/2016:11:43:53 +0000] "OPTIONS /svntest/fakerepo
> HTTP/1.1" 200 196
> 172.17.42.1 - alice [31/Aug/2016:11:43:53 +0000] "OPTIONS /svntest/fakerepo
> HTTP/1.1" 200 97
> 172.17.42.1 - alice [31/Aug/2016:11:43:53 +0000] "POST
> /svntest/fakerepo/!svn/me HTTP/1.1" 201 -
> 172.17.42.1 - alice [31/Aug/2016:11:43:53 +0000] "DELETE
> /svntest/fakerepo/!svn/txr/13-g/tags HTTP/1.1" 204 -
> 172.17.42.1 - alice [31/Aug/2016:11:43:53 +0000] "MERGE /svntest/fakerepo
> HTTP/1.1" 200 756
>
As you see Subversion perform DELETE directly, without CHECKOUT when
using HTTPv2 protocol. That's expected behavior.
--
Ivan Zhakov
Re: Permissions need for deletion
Posted by "Vacelet, Manuel" <ma...@enalean.com>.
On Wed, Aug 31, 2016 at 12:37 PM, Ivan Zhakov <iv...@visualsvn.com> wrote:
> On 31 August 2016 at 13:28, Vacelet, Manuel <ma...@enalean.com>
> wrote:
> > On Wed, Aug 31, 2016 at 12:19 PM, Ivan Zhakov <iv...@visualsvn.com>
> wrote:
> >>
> >>
> >> > - Why this behaviour changed between 1.6 and newer ?
> >> It was bug before Subversion 1.7.9. The problem was that client tried
> >> to read some information from repository root when performing remove
> >> folder. See SVN-4332 for more details [1]
> >>
> >> [1] https://issues.apache.org/jira/browse/SVN-4332
> >>
> >
> > I did read that but in my tests, when server is 1.6, whatever version of
> > client (1.6, 1.7, 1.8, 1.9), cannot remove.
> >
> > When server is 1.8, behaviour change depending on client version so it
> might
> > be related to this issue (even if in all cases, the user has access to
> the
> > root).
> >
> It's could be related to HTTPv2 protocol introduced in Subversion 1.7.
> Could you provide requests log with svn server 1.6?
>
> [1] https://subversion.apache.org/docs/release-notes/1.7.html#httpv2
>
>
Here we go, on client side, svn, version 1.9.3 (r1718519)
Server is svn, version 1.6.11 (r934486)
172.17.42.1 - - [31/Aug/2016:11:52:37 +0000] "OPTIONS
/svntest/fakerepo/tags HTTP/1.1" 401 501
172.17.42.1 - alice [31/Aug/2016:11:52:37 +0000] "OPTIONS
/svntest/fakerepo/tags HTTP/1.1" 200 196
172.17.42.1 - alice [31/Aug/2016:11:52:37 +0000] "OPTIONS
/svntest/fakerepo/tags HTTP/1.1" 200 97
172.17.42.1 - alice [31/Aug/2016:11:52:37 +0000] "PROPFIND
/svntest/fakerepo/tags HTTP/1.1" 207 700
172.17.42.1 - alice [31/Aug/2016:11:52:37 +0000] "PROPFIND
/svntest/fakerepo/tags HTTP/1.1" 207 325
172.17.42.1 - alice [31/Aug/2016:11:52:40 +0000] "MKACTIVITY
/svntest/fakerepo/!svn/act/8267278f-ed0c-42db-a6c8-65f010a954c9 HTTP/1.1"
201 337
172.17.42.1 - alice [31/Aug/2016:11:52:40 +0000] "PROPFIND
/svntest/fakerepo HTTP/1.1" 207 400
172.17.42.1 - alice [31/Aug/2016:11:52:40 +0000] "CHECKOUT
/svntest/fakerepo/!svn/vcc/default HTTP/1.1" 201 352
172.17.42.1 - alice [31/Aug/2016:11:52:40 +0000] "PROPPATCH
/svntest/fakerepo/!svn/wbl/8267278f-ed0c-42db-a6c8-65f010a954c9/15
HTTP/1.1" 207 469
172.17.42.1 - alice [31/Aug/2016:11:52:40 +0000] "CHECKOUT
/svntest/fakerepo/!svn/ver/15 HTTP/1.1" 403 330
172.17.42.1 - alice [31/Aug/2016:11:52:40 +0000] "DELETE
/svntest/fakerepo/!svn/act/8267278f-ed0c-42db-a6c8-65f010a954c9 HTTP/1.1"
204 -
Server is svn, version 1.8.16 (r1740329):
172.17.42.1 - - [31/Aug/2016:11:43:53 +0000] "OPTIONS /svntest/fakerepo
HTTP/1.1" 401 501
172.17.42.1 - alice [31/Aug/2016:11:43:53 +0000] "OPTIONS /svntest/fakerepo
HTTP/1.1" 200 196
172.17.42.1 - alice [31/Aug/2016:11:43:53 +0000] "OPTIONS /svntest/fakerepo
HTTP/1.1" 200 97
172.17.42.1 - alice [31/Aug/2016:11:43:53 +0000] "POST
/svntest/fakerepo/!svn/me HTTP/1.1" 201 -
172.17.42.1 - alice [31/Aug/2016:11:43:53 +0000] "DELETE
/svntest/fakerepo/!svn/txr/13-g/tags HTTP/1.1" 204 -
172.17.42.1 - alice [31/Aug/2016:11:43:53 +0000] "MERGE /svntest/fakerepo
HTTP/1.1" 200 756
> >> But according to provided authz file 'alice' has read access to
> >> repository root, so it may be different issue. Anyway, your authz file
> >> allows 'alice' to remove /tags.
> >
> > OK thanks for the info, do you know if it's documented / specified
> somewhere
> > ?
> > I tried to get this info from
> > http://svnbook.red-bean.com/nightly/en/svn.serverconfig.
> pathbasedauthz.html
> > but those rules are not described.
> >
> I'm not aware about documentation, but it seems natural that user only
> need write to resource to remove it.
>
I agree too but the point here is that behaviour changed.
Re: Permissions need for deletion
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 31 August 2016 at 13:28, Vacelet, Manuel <ma...@enalean.com> wrote:
> On Wed, Aug 31, 2016 at 12:19 PM, Ivan Zhakov <iv...@visualsvn.com> wrote:
>>
>>
>> > - Why this behaviour changed between 1.6 and newer ?
>> It was bug before Subversion 1.7.9. The problem was that client tried
>> to read some information from repository root when performing remove
>> folder. See SVN-4332 for more details [1]
>>
>> [1] https://issues.apache.org/jira/browse/SVN-4332
>>
>
> I did read that but in my tests, when server is 1.6, whatever version of
> client (1.6, 1.7, 1.8, 1.9), cannot remove.
>
> When server is 1.8, behaviour change depending on client version so it might
> be related to this issue (even if in all cases, the user has access to the
> root).
>
It's could be related to HTTPv2 protocol introduced in Subversion 1.7.
Could you provide requests log with svn server 1.6?
[1] https://subversion.apache.org/docs/release-notes/1.7.html#httpv2
>> But according to provided authz file 'alice' has read access to
>> repository root, so it may be different issue. Anyway, your authz file
>> allows 'alice' to remove /tags.
>
> OK thanks for the info, do you know if it's documented / specified somewhere
> ?
> I tried to get this info from
> http://svnbook.red-bean.com/nightly/en/svn.serverconfig.pathbasedauthz.html
> but those rules are not described.
>
I'm not aware about documentation, but it seems natural that user only
need write to resource to remove it.
--
Ivan Zhakov
Re: Permissions need for deletion
Posted by "Vacelet, Manuel" <ma...@enalean.com>.
On Wed, Aug 31, 2016 at 12:19 PM, Ivan Zhakov <iv...@visualsvn.com> wrote:
>
> > - Why this behaviour changed between 1.6 and newer ?
> It was bug before Subversion 1.7.9. The problem was that client tried
> to read some information from repository root when performing remove
> folder. See SVN-4332 for more details [1]
>
> [1] https://issues.apache.org/jira/browse/SVN-4332
>
>
I did read that but in my tests, when server is 1.6, whatever version of
client (1.6, 1.7, 1.8, 1.9), cannot remove.
When server is 1.8, behaviour change depending on client version so it
might be related to this issue (even if in all cases, the user has access
to the root).
But according to provided authz file 'alice' has read access to
> repository root, so it may be different issue. Anyway, your authz file
> allows 'alice' to remove /tags.
>
OK thanks for the info, do you know if it's documented / specified
somewhere ?
I tried to get this info from
http://svnbook.red-bean.com/nightly/en/svn.serverconfig.pathbasedauthz.html
but those rules are not described.
Re: Permissions need for deletion
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 31 August 2016 at 13:04, Vacelet, Manuel <ma...@enalean.com> wrote:
> On Thu, Aug 25, 2016 at 11:29 AM, Ivan Zhakov <iv...@visualsvn.com> wrote:
>>
>> On 25 August 2016 at 12:19, Vacelet, Manuel <ma...@enalean.com>
>> wrote:
[...]
>
> Ivan,
>
Hi Manuel,
> 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) ?
To remove folder user only need write access to the folders and all
it's children
> - Why this behaviour changed between 1.6 and newer ?
It was bug before Subversion 1.7.9. The problem was that client tried
to read some information from repository root when performing remove
folder. See SVN-4332 for more details [1]
[1] https://issues.apache.org/jira/browse/SVN-4332
But according to provided authz file 'alice' has read access to
repository root, so it may be different issue. Anyway, your authz file
allows 'alice' to remove /tags.
--
Ivan Zhakov
Re: Permissions need for deletion
Posted by "Vacelet, Manuel" <ma...@enalean.com>.
On Thu, Aug 25, 2016 at 11:29 AM, Ivan Zhakov <iv...@visualsvn.com> wrote:
> On 25 August 2016 at 12:19, Vacelet, Manuel <ma...@enalean.com>
> wrote:
> > On Thu, Aug 25, 2016 at 11:13 AM, Ivan Zhakov <iv...@visualsvn.com>
> wrote:
> >>
> >> On 25 August 2016 at 11:50, Vacelet, Manuel <manuel.vacelet@enalean.com
> >
> >> wrote:
> >> > On Wed, Aug 24, 2016 at 5:46 PM, Vacelet, Manuel
> >> > <ma...@enalean.com> wrote:
> >> >>
> >> >> oops I hit shift+enter :/
> >> >> see my message below
> >> >>
> >> >> On Wed, Aug 24, 2016 at 5:44 PM, Vacelet, Manuel
> >> >> <ma...@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
Re: Permissions need for deletion
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 25 August 2016 at 12:19, Vacelet, Manuel <ma...@enalean.com> wrote:
> On Thu, Aug 25, 2016 at 11:13 AM, Ivan Zhakov <iv...@visualsvn.com> wrote:
>>
>> On 25 August 2016 at 11:50, Vacelet, Manuel <ma...@enalean.com>
>> wrote:
>> > On Wed, Aug 24, 2016 at 5:46 PM, Vacelet, Manuel
>> > <ma...@enalean.com> wrote:
>> >>
>> >> oops I hit shift+enter :/
>> >> see my message below
>> >>
>> >> On Wed, Aug 24, 2016 at 5:44 PM, Vacelet, Manuel
>> >> <ma...@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
(I've checked wrong duplicated issue before)
--
Ivan Zhakov
Re: Permissions need for deletion
Posted by "Vacelet, Manuel" <ma...@enalean.com>.
On Thu, Aug 25, 2016 at 11:13 AM, Ivan Zhakov <iv...@visualsvn.com> wrote:
> On 25 August 2016 at 11:50, Vacelet, Manuel <ma...@enalean.com>
> wrote:
> > On Wed, Aug 24, 2016 at 5:46 PM, Vacelet, Manuel
> > <ma...@enalean.com> wrote:
> >>
> >> oops I hit shift+enter :/
> >> see my message below
> >>
> >> On Wed, Aug 24, 2016 at 5:44 PM, Vacelet, Manuel
> >> <ma...@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).
Re: Permissions need for deletion
Posted by Stefan Hett <st...@egosoft.com>.
On 8/25/2016 11:52 AM, Stefan Hett wrote:
> On 8/25/2016 11:35 AM, Ivan Zhakov wrote:
>> On 25 August 2016 at 12:30, Stefan Hett <st...@egosoft.com> wrote:
>>> On 8/25/2016 11:13 AM, Ivan Zhakov wrote:
>>>> On 25 August 2016 at 11:50, Vacelet, Manuel
>>>> <ma...@enalean.com>
>>>> wrote:
>>>>> On Wed, Aug 24, 2016 at 5:46 PM, Vacelet, Manuel
>>>>> <ma...@enalean.com> wrote:
>>>>>> oops I hit shift+enter :/
>>>>>> see my message below
>>>>>>
>>>>>> On Wed, Aug 24, 2016 at 5:44 PM, Vacelet, Manuel
>>>>>> <ma...@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
>>> According to SVN-4219 the issue was present in 1.7 and also fixed in
>>> 1.7, or
>>> is the JIRA issue record wrong in this regards?
>>> Also I take it that with Manuel's report here, the issue was not only
>>> present in 1.7 but also existed on 1.6. Otherwise I think I'm missing
>>> something.
>>>
>> The SVN-4219 is duplicate issue for SVN-4332.
> Right, but what gets me confused there is that SVN-4332 explicitly
> states: "The 1.6/neon client can delete /A/B [...] but the 1.7/neon
> client fails[...]". That suggests to me the issue wouldn't be present
> with 1.6 but only with 1.7.0-1.7.9.
> This would be contradicting to the OP report that removing the file is
> possible with his 1.6 client.
Of cause this should read: "[...] OP's report that removing the file is
*NOT* possible with his 1.6 client.
>
> I take it, it's not worth continuing checking the history here, since
> the unquestionable conclusion is is that the behavior the OP sees in
> 1.7+ is the correct one by design (aka: having write access to a path
> allows also to delete that path - FWIW: That's not quite what I'd
> expect, since I would assume that I also need write access to the
> parent path in order to remove a directory/path since that's also the
> access I require to create that directory/path).
>
--
Regards,
Stefan Hett
Re: Permissions need for deletion
Posted by Stefan Hett <st...@egosoft.com>.
On 8/25/2016 11:35 AM, Ivan Zhakov wrote:
> On 25 August 2016 at 12:30, Stefan Hett <st...@egosoft.com> wrote:
>> On 8/25/2016 11:13 AM, Ivan Zhakov wrote:
>>> On 25 August 2016 at 11:50, Vacelet, Manuel <ma...@enalean.com>
>>> wrote:
>>>> On Wed, Aug 24, 2016 at 5:46 PM, Vacelet, Manuel
>>>> <ma...@enalean.com> wrote:
>>>>> oops I hit shift+enter :/
>>>>> see my message below
>>>>>
>>>>> On Wed, Aug 24, 2016 at 5:44 PM, Vacelet, Manuel
>>>>> <ma...@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
>> According to SVN-4219 the issue was present in 1.7 and also fixed in 1.7, or
>> is the JIRA issue record wrong in this regards?
>> Also I take it that with Manuel's report here, the issue was not only
>> present in 1.7 but also existed on 1.6. Otherwise I think I'm missing
>> something.
>>
> The SVN-4219 is duplicate issue for SVN-4332.
Right, but what gets me confused there is that SVN-4332 explicitly
states: "The 1.6/neon client can delete /A/B [...] but the 1.7/neon
client fails[...]". That suggests to me the issue wouldn't be present
with 1.6 but only with 1.7.0-1.7.9.
This would be contradicting to the OP report that removing the file is
possible with his 1.6 client.
I take it, it's not worth continuing checking the history here, since
the unquestionable conclusion is is that the behavior the OP sees in
1.7+ is the correct one by design (aka: having write access to a path
allows also to delete that path - FWIW: That's not quite what I'd
expect, since I would assume that I also need write access to the parent
path in order to remove a directory/path since that's also the access I
require to create that directory/path).
--
Regards,
Stefan Hett
Re: Permissions need for deletion
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 25 August 2016 at 12:30, Stefan Hett <st...@egosoft.com> wrote:
> On 8/25/2016 11:13 AM, Ivan Zhakov wrote:
>>
>> On 25 August 2016 at 11:50, Vacelet, Manuel <ma...@enalean.com>
>> wrote:
>>>
>>> On Wed, Aug 24, 2016 at 5:46 PM, Vacelet, Manuel
>>> <ma...@enalean.com> wrote:
>>>>
>>>> oops I hit shift+enter :/
>>>> see my message below
>>>>
>>>> On Wed, Aug 24, 2016 at 5:44 PM, Vacelet, Manuel
>>>> <ma...@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
>
> According to SVN-4219 the issue was present in 1.7 and also fixed in 1.7, or
> is the JIRA issue record wrong in this regards?
> Also I take it that with Manuel's report here, the issue was not only
> present in 1.7 but also existed on 1.6. Otherwise I think I'm missing
> something.
>
The SVN-4219 is duplicate issue for SVN-4332.
--
Ivan Zhakov
Re: Permissions need for deletion
Posted by Stefan Hett <st...@egosoft.com>.
On 8/25/2016 11:13 AM, Ivan Zhakov wrote:
> On 25 August 2016 at 11:50, Vacelet, Manuel <ma...@enalean.com> wrote:
>> On Wed, Aug 24, 2016 at 5:46 PM, Vacelet, Manuel
>> <ma...@enalean.com> wrote:
>>> oops I hit shift+enter :/
>>> see my message below
>>>
>>> On Wed, Aug 24, 2016 at 5:44 PM, Vacelet, Manuel
>>> <ma...@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
According to SVN-4219 the issue was present in 1.7 and also fixed in
1.7, or is the JIRA issue record wrong in this regards?
Also I take it that with Manuel's report here, the issue was not only
present in 1.7 but also existed on 1.6. Otherwise I think I'm missing
something.
--
Regards,
Stefan Hett
Re: Permissions need for deletion
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 25 August 2016 at 11:50, Vacelet, Manuel <ma...@enalean.com> wrote:
> On Wed, Aug 24, 2016 at 5:46 PM, Vacelet, Manuel
> <ma...@enalean.com> wrote:
>>
>> oops I hit shift+enter :/
>> see my message below
>>
>> On Wed, Aug 24, 2016 at 5:44 PM, Vacelet, Manuel
>> <ma...@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
--
Ivan Zhakov
Re: Permissions need for deletion
Posted by "Vacelet, Manuel" <ma...@enalean.com>.
On Wed, Aug 24, 2016 at 5:46 PM, Vacelet, Manuel <manuel.vacelet@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@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.
For references, the httpd traces:
client 1.6 / server 1.8
172.17.42.6 - - [25/Aug/2016:08:29:07 +0000] "OPTIONS
/svntest/fakerepo/tags HTTP/1.1" 401 501
172.17.42.6 - alice [25/Aug/2016:08:29:07 +0000] "OPTIONS
/svntest/fakerepo/tags HTTP/1.1" 200 196
172.17.42.6 - alice [25/Aug/2016:08:29:07 +0000] "PROPFIND
/svntest/fakerepo/tags HTTP/1.1" 207 700
172.17.42.6 - alice [25/Aug/2016:08:29:07 +0000] "PROPFIND
/svntest/fakerepo/!svn/vcc/default HTTP/1.1" 207 414
172.17.42.6 - alice [25/Aug/2016:08:29:07 +0000] "PROPFIND
/svntest/fakerepo/!svn/bln/7 HTTP/1.1" 207 465
172.17.42.6 - alice [25/Aug/2016:08:29:07 +0000] "PROPFIND
/svntest/fakerepo/!svn/bc/7/tags HTTP/1.1" 207 710
172.17.42.6 - alice [25/Aug/2016:08:29:07 +0000] "PROPFIND
/svntest/fakerepo/tags HTTP/1.1" 207 700
172.17.42.6 - alice [25/Aug/2016:08:29:07 +0000] "PROPFIND
/svntest/fakerepo/!svn/vcc/default HTTP/1.1" 207 414
172.17.42.6 - alice [25/Aug/2016:08:29:07 +0000] "PROPFIND
/svntest/fakerepo/!svn/bln/7 HTTP/1.1" 207 465
172.17.42.6 - alice [25/Aug/2016:08:29:07 +0000] "MKACTIVITY
/svntest/fakerepo/!svn/act/62c9c93e-15c7-4a03-9e1e-2ec445366e1d HTTP/1.1"
201 337
172.17.42.6 - alice [25/Aug/2016:08:29:07 +0000] "CHECKOUT
/svntest/fakerepo/!svn/vcc/default HTTP/1.1" 201 351
172.17.42.6 - alice [25/Aug/2016:08:29:07 +0000] "PROPPATCH
/svntest/fakerepo/!svn/wbl/62c9c93e-15c7-4a03-9e1e-2ec445366e1d/7 HTTP/1.1"
207 468
172.17.42.6 - alice [25/Aug/2016:08:29:07 +0000] "PROPFIND
/svntest/fakerepo HTTP/1.1" 207 399
172.17.42.6 - alice [25/Aug/2016:08:29:07 +0000] "CHECKOUT
/svntest/fakerepo/!svn/ver/7/ HTTP/1.1" 403 330
172.17.42.6 - alice [25/Aug/2016:08:29:07 +0000] "DELETE
/svntest/fakerepo/!svn/act/62c9c93e-15c7-4a03-9e1e-2ec445366e1d HTTP/1.1"
204 -
client 1.7 / server 1.8
172.17.42.8 - - [25/Aug/2016:08:37:34 +0000] "OPTIONS
/svntest/fakerepo/tags HTTP/1.1" 401 501
172.17.42.8 - alice [25/Aug/2016:08:37:34 +0000] "OPTIONS
/svntest/fakerepo/tags HTTP/1.1" 200 196
172.17.42.8 - alice [25/Aug/2016:08:37:34 +0000] "PROPFIND
/svntest/fakerepo/tags HTTP/1.1" 207 700
172.17.42.8 - alice [25/Aug/2016:08:37:34 +0000] "POST
/svntest/fakerepo/!svn/me HTTP/1.1" 201 -
172.17.42.8 - alice [25/Aug/2016:08:37:34 +0000] "PROPPATCH
/svntest/fakerepo/!svn/txn/11-e HTTP/1.1" 207 434
172.17.42.8 - alice [25/Aug/2016:08:37:34 +0000] "DELETE
/svntest/fakerepo/!svn/txr/11-e/tags HTTP/1.1" 204 -
172.17.42.8 - alice [25/Aug/2016:08:37:34 +0000] "MERGE /svntest/fakerepo
HTTP/1.1" 200 485
client 1.9 / server 1.8
172.17.42.1 - - [25/Aug/2016:08:29:41 +0000] "OPTIONS
/svntest/fakerepo/tags HTTP/1.1" 401 501
172.17.42.1 - alice [25/Aug/2016:08:29:41 +0000] "OPTIONS
/svntest/fakerepo/tags HTTP/1.1" 200 196
172.17.42.1 - alice [25/Aug/2016:08:29:41 +0000] "OPTIONS
/svntest/fakerepo/tags HTTP/1.1" 200 97
172.17.42.1 - alice [25/Aug/2016:08:29:41 +0000] "PROPFIND
/svntest/fakerepo/tags HTTP/1.1" 207 325
172.17.42.1 - alice [25/Aug/2016:08:29:41 +0000] "POST
/svntest/fakerepo/!svn/me HTTP/1.1" 201 -
172.17.42.1 - alice [25/Aug/2016:08:29:41 +0000] "DELETE
/svntest/fakerepo/!svn/txr/7-a/tags HTTP/1.1" 204 -
172.17.42.1 - alice [25/Aug/2016:08:29:41 +0000] "MERGE /svntest/fakerepo
HTTP/1.1" 200 754
Re: Permissions need for deletion
Posted by "Vacelet, Manuel" <ma...@enalean.com>.
oops I hit shift+enter :/
see my message below
On Wed, Aug 24, 2016 at 5:44 PM, Vacelet, Manuel <manuel.vacelet@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 ?