VisualSVN 2.5.16 on a server, Tortoise SVN 1.8.1 as a client on a development machine.
I've set up permissions on the VisualSVN Server Manger for someone to give them access to a repo. The permissions seem to reflect in the 'browse repo' interface, but not in the update/commit actions from TortoiseSVN when it talks to the VisualSVN server.
Example: I went to the project I've been working on for months and test - remove my permissions in VisualSVN server manager so all Everyone has No Access, and the developer group has No Access. IE no on has access at this point. Yet I can still create a test file, and commit it to the repo. Then go and delete the file form the repo and commit that. I don't seem to be able to revoke permissions for me to read or write to the repo.
The change has made the repository now show up in the "Repository Browser" of TortoiseSVN (ie I cannot see the tree branch I removed my permissions to), but the update/commit actions from the Windows 7 file explorer context menu still work just fine.
I'm wondering if the same sort of oddness is what is preventing my colleague from accessing the repository to commit changes, despite him having been explicitly been given read/write permissions to the other repository he is working on.
The root problem I'm trying to solve is why a colleague has read-only access to a part of the repository, where the only two modes of access granted are "no access" for 'everyone' and "read/write" access for our dev group and him explicitly. He is authenticating against VisualSVN using that explicit login, but only gets read-only access. According to the VisualSVN docs, by virtue of his name being explicitly being granted read/write access, that would grant him that over any inheritance or the 'everyone' access on the repository folder.
Something odd is at play between VisualSVN Standard Edition with explicit accounts and TortoiseSVN on Windows 7.