[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Authz permisison problem after upgrade from 1.6.16 to 1.7.1

From: Jens Geyer <jgx_at_vsx.net>
Date: Thu, 10 Nov 2011 17:09:54 +0100

Hi *,

I have an really interesting case here, which looks to me like an bug.

The behavior started after the upgrade of our SVN server from 1.6.16 to
1.7.1.
We use a windows server (SVNSERVE) here, I haven't tested this on
Apache.

The scenario:
We have a source code tree, which lives let's say under

        /trunk/testApp

In the SVN root, we have some more folders, such as

        /branches

We also have a build server, who checks the source out into his local
WC.
After the successful build, the build server sets an tag under

        /tags/buildserver/testApp

Which he does by means of svn copy (I can provide the exact command, if
neceassary).
This works, if I configure the access control file like this:

        [/tags]
        Buildserver = rw
        * = r

        [/trunk]
        Buildserver = rw
        * = r

         [/]
        Buildserver = rw
        * = r

It does no longer work (the svn copy command fails with "access denied")
when I add /branches to the access configuration:

        [/tags]
        Buildserver = rw
        * = r

        [/trunk]
        Buildserver = rw
        * = r

        [/branches]
        * = r

         [/]
        Buildserver = rw
        * = r

It starts to work again, if I give the buildserver explicit write
access to [/branches].

==> Please note, that /branches is not affected by the copy, neither as
source, nor as the target.
==> This looks like a clear bug to me.

Again, I were not able to found any documentation about such changes in
the access control logic.
Is there some documentation around about these new "features" of svn
1.7?

JensG
Received on 2011-11-10 17:10:31 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.