On 8/25/2016 11:35 AM, Ivan Zhakov wrote:
On 25 August 2016 at 12:30, Stefan Hett <ste...@egosoft.com> wrote:
On 8/25/2016 11:13 AM, Ivan Zhakov 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
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
