Using working copy with multiple user accounts with different permissions

Question

I use VisualSVN Server and a repository with 3 users and TortoiseSVN as a client. Two users have full access and are committing all changes. The third user is used for a public (company shared drive, not fully public) readonly checkout folder. Authentication is basic from VisualSVN Server. The structure is as follows:

\
\branches
\tags
\trunk
\trunk\internal

internal folder is set as no access for the third public user. Other real users are not actively using SVN, but only accessing this checked out \trunk folder on the shared drive. This checked out folder is automatically updated with the hook after commit.

If that checked out folder is updated with the public username and password the internal folder will not be shown. And that's how it should work.

If I accidentally update this folder with my username and password which has read/write rights on the internal folder, this internal folder is shown. Which is also correct.

After this update I realize the error and want to update the folder with the public username and password, but internal folder is not removed/deleted from working copy. And this is 100% not OK. If I specifically update the internal folder only with the public username, I get the error that update is forbidden. This is also OK, but the folder is still there. If I delete the internal folder and update the working copy with public username, internal folder is restored. That's really not OK.

What I know until now is that this has something to do with permissions. E.g.:

• public user commits a file
• I remove access to this file for the public user on the server
• public user updates the working copy and this file is removed/deleted correctly
• if I update with other username, the file is shown
• if I update again with public user, the file is not removed/deleted

So, which app is not working correctly? I excluded TortoiseSVN because the same thing happens when I update through cmd. That leaves SVN and VisualSVN Server.

P.S. In theory I could move the internal folder outside of trunk, since only trunk is checked out on the shared drive, but I would like to find a solution for this scenario.

Answer 1

AFAIK, this is how Subversion client works by design and is generally not considered as an issue. The behavior is controlled by the Subversion client, not the server.

1. Why don't you let your users have their own working copies? Or at least don't update the working copy with user credentials. Use only the credentials specified in your hook script for that working copy.

2. You can leave the data on a network share if you need this, but hide the .svn metadata directory with user permissions on the share. Or use svn export instead of working copy and update it exclusively from a hook script.

3. You can move your project's layout into a subdirectory. But leave the /internal directory in the root of your repository. The check out a working copy of the new project directory. The directory /internal won't appear in the shared working copy even if you accidentally use unwanted credentials when updating it.

When a user does not have Read or Read / Write permissions to a directory or a file, he will not see this file or directory in a repository, and the user is unable to download it from the server and repository. The only exception is a user's local working copy that was checked out or updated when a user had Read permissions. But this is essentially the same case as if the user downloaded the file to his disk when he had sufficient access. Assume you have a network share, and a user had Read access to a file on this share. He downloads this file to his disk. Then you revoke his access to this file. This action does not remove the file from the user's disk but prevents him from updating this file or downloading it again.

Deleting the /internal directory in the working copy locally won't remove it from the .svn metadata directory. So updating the working copy will again restore the file from the pristine area of the .svn directory.

PS You may also file a feature request or ask a usage question in the users@ Apache Subversion mailing list.