I have a svn repository using authz to control the access. The structure looks like this:
├── branches
│ └── bob
├── tags
└── trunk
└── A
├── B
│ └── README.txt
└── README.txt
Suppose the authz grants a user read access to directory A but not B, and it fails when I try to branch A:
[hidden]$ svn copy A ^/branches/bob/A1 -m 'Branching A to branches/bob/A1'
Adding copy of A
svn: E220001: Commit failed (details follow):
svn: E220001: Access denied
The svnserve's log says
Authorization Failed recursive read /trunk/A
Why does svn has this restriction and is there a way to work around? Why doesn't it just ignore B when branching, just the same as doing a checkout?
If this turns out to be impossible, then what's the best workflow for svn with authz? It looks if branching is not allowed, the only way is everyone working on the trunk, but this is too stupid.
SVN's initial authz implementation didn't check the whole subtree on copy, but added later to address this security hole.
So the conclusion is, SVN's authz was not designed well from beginning, sooner or later lots of hacky and dirty fixes got in, which eventually made your use case unsupported. IMHO a good implementation should just keep track of where a branch was copied from and check authz of the source as well.
I agree your use case is totally valid and Perforce supports path-based-authorization pretty well. Unfortunately you can't do it in svn. You can either switch to Perforce, or wait for them to improve authz.