svn repository on Windows network share

Question

Is it safe for multiple computers to concurrently access an svn repository stored on a shared filesystem?

I'm building an application in which each Windows client machine has a local working set of files, and can periodically synchronize with the rest of the team. From a server standpoint, I'd like to rely on nothing except a Windows shared mount point. Does the svn file:// URL protocol support shared filesystems, or does it assume that the filesystem is local?

The Subversion docs mention issues with BDB and FSFS in Win9x environments, but it's not clear to me whether or not repositories concurrently accessed via file:// URLs are safe in more recent versions of Windows (or other operating systems, for that matter).

Edit The application I'm building will be using svn directly, so I'm willing to build a relatively constrained environment if it'll permit a safe concurrent shared collaboration environment.

Solution 1

Another question is similar, but was asked re: performance: Subversion protocol performance

The SVN Book recommends that you do not use the file:// protocol for multiple users

Choosing a Server Configuration:

Do not be seduced by the simple idea of having all of your users access a repository directly via file:// URLs. Even if the repository is readily available to everyone via a network share, this is a bad idea. It removes any layers of protection between the users and the repository: users can accidentally (or intentionally) corrupt the repository database, it becomes hard to take the repository offline for inspection or upgrade, and it can lead to a mess of file permission problems (see the section called “Supporting Multiple Repository Access Methods”). Note that this is also one of the reasons we warn against accessing repositories via svn+ssh:// URLs—from a security standpoint, it's effectively the same as local users accessing via file://, and it can entail all the same problems if the administrator isn't careful

Solution 2

From a technical point of view it is perfectly possible to use the file:// protocol with multiple users:

The corruption will NOT occur on standard svn usage, as subversion uses its own locking mechanisms on FSFS. Otherwise the SVN book would state clearly to avoid such a setup as it mentioned this issue in BDB backend.

However, the real problem is how to limit the access to the repository database to not access the repository data with any other arbitrary tool?

If you use file:// everybody can open each file inside your SVN repository and change its contents which will lead surely to repository corruption.

Heck, every user can delete the whole repository!

You cannot limit the access to svn tools and so you should not use file:// protocol.

Solution 3

I think you're setting yourself up for problems with this approach. Windows CIFS (the windows file sharing protocol) has a lot of known issues with oplocking and simultaneous modification, so it's either going to be dog slow, unsafe, or both.

A much, much, better solution is to set up a real SVN server instead of using file:// URLs.

Solution 4

Off the top of my head (and I was not able to find any information online), I would think that if you are using an SVN client that supports the file:// protocol (TortoiseSVN, for example), it should work correctly.

However, and unfortunately I cannot find the document, I do remember there being certain problems with the file:// protocol and SVN. If possible, I would suggest setting up an SVN server (VisualSVN works very nicely and is easy to setup) rather than relying on a Windows share.

Edit: I found this discussion on Stackoverflow. It seems as though there is not a problem using the file protocol.

Edit 2: Neil's link is what I had read awhile back and does discourage the file protocol. However, if using the file:// protocol means the difference between using and not using source control, I would recommend at least using that. Some source control is better than nothing.

Solution 5

That's right bro...

I've been there. I too used the file system to share the "svn server" between a couple of machines... The only thing I got was corrupted files and big headaches...

Instaled a svn server (CollabNetSubversion Server), and now everything is running smooth... Except for the times I screw it myself... but this is another story....

Cheers.

Aldo

View more solutions