To access an svn+ssh URL the svn client launches an svnserve instance using "ssh -q user@host svnserve -t" and talks with that instance through stdin/stdout.
If your users need normal ssh access you can still prevent them from accessing the repository by limiting access to one user (chown -R svnserve:svnserve repo; chmod -R g-rwx,o-rwx repo) and by replacing the svnserve command by this setuid/setgid svnserve wrapper program.
They won't use SVN? Honestly, I'd do my best to shove it down their throats (any end user can use TortoiseSVN with a minimal of re-training) if at all possible. There's no reason you should have to hack around their laziness.
As far as I see it, there are at least two ways of hacking it --
- Create separate working copies and hand-manage SVN for each
I actually have the same problem at my place of work, and my boss told me that we can't force them to use it. Instead, we create a network share for each developer/group which needs access to the code, then manually svn up
/svn commit
for them upon request.
- Have one "Master" working copy and hand out SMB/FTP/NFS access to it
We have a terrible setup with another group -- they didn't want to use SVN, so we just gave them raw Samba access to the production machine to tinker with the files. Then, every night a cron job goes through and adds all the new files and commits it to the repo. Since there's only one working copy there aren't ever any conflicts. Honestly it's serves little purpose except to make me sleep a little sounder at night.
They're both absolutely stupid ways of doing it -- the first requires hand conflict resolution (by you, or a member of your team) and the other has practically no advantage over the disk backups. IMHO the only real solution is to teach your end-users not only how to use SVN, but why they should be using it. That way they can be responsible for their own work, leaving you to deal with the real problems.
Best Answer
The SVN repository itself doesn't contain the files in the format that they were committed in.
Instead, the repository's storage uses either FSFS or BDB as storage - most likely for a modern repository, the FSFS format is used.
You probably shouldn't be mucking around much with the files in the repository itself; it's very easy to blow things up, and most cases where you need to work with the repository directly should be handled in the
svnadmin
command.If you're just needing the contents of the repository locally on the server, use
svn checkout file:///home/svn/repo/
.