Svn – How to set up a read-only file system mirror for an SVN repository

svn

I've got an SVN repository that lives on a Windows network drive (and accessed through a file url). A number of my coworkers can't and won't use SVN, so I need to maintain a read-only mirror of everything in the repository in another directory.

I don't see any easy way to do it. I can't make it a working copy, because that chews up too much network space. svn export won't remove files which are deleted from the repository. I was trying to create a hook script to copy files over when they're checked in, but I can't guarantee the path to the SVN executable will be the same for every client.

I was going to simply have a script which I manually run which compares each file in the repository with the file on the network and either deletes or copies it if there's a mismatch, but I can't seem to get the size of the file from the repository, which means I would have to rely solely on the reported change date of the file–which I'm reluctant to do.

What's the best way of getting this set up?

Best Answer

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.

Related Topic