svn repository on Windows network share

views:

1158

answers:

+3 Q:

svn repository on Windows network share

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.

+1 A:

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.

JasCav 2009-08-17 19:18:53

I agree with using VisualSVN over a share.

Nick 2009-08-17 19:21:11

I disagree strongly with your second edit - unreliable source control is worse than none at all.

anon 2009-08-17 19:28:53

+8 A:

The Tortoise SVN docs actually strongly discourage it - see this link. .

To summarise:

file:// access is intended for local, single-user access only, particularly testing and debugging.

anon 2009-08-17 19:19:56

Those are the TortoiseSVN docs, not the svn docs themselves. I wonder whether that's a limitation / opinion of the TortoiseSVN guys, or a problem with svn itself.Also, I'm willing to make a lot of concessions around environment restrictions; if I can find a narrow set of requirements that *do* work, I'll happily constrain myself to them (assuming that one of the requirements isn't "run a server process").

Patrick Linskey 2009-08-17 19:26:27

I somehow suspect that the Tortoise developers know a bit more about Subveersion than you or I do. Tortoise is built on the Subversion code, so I would guess it is a basic Subversion limitation.

anon 2009-08-17 19:35:03

They certainly know more than I do, but I wouldn't be surprised if their recommendations are for pretty general-purpose usage. I'm willing to make a lot of concessions to avoid writing my own distributed file sharing code, so am more interested in what is possible to do safely, rather than what is recommended.

Patrick Linskey 2009-08-17 19:37:28

Well, I think you are making a big mistake. Use of single-user software on Windows shares by multiple users has always been fraught with problems. But it's your funeral.

anon 2009-08-17 19:41:13

Understood. It's not clear to me that svn + file:// is "single-user software", though. Some distributed filesystems do support locking, and with that, it's certainly possible to build a correct solution. I'm unsure if svn is one such solution, though.

Patrick Linskey 2009-08-17 19:46:21

From personal experience, I would NOT do this! Just setup a server. It's not hard and will save you many headaches.

Judge Maygarden 2009-08-17 19:47:58

Judge: what experiences are you referring to? In my environment, I cannot deploy a server, so that's not an option.

Patrick Linskey 2009-08-18 00:16:23

@Patrick: Then set up some server in a virtual machine and run that on some machine.

sbi 2009-08-18 09:10:10

I think the phrase "set up a server" makes people run away screaming. All we're actually talking about here is running svnserve or an apache module on some system somewhere. You can put it on your own desktop if you want (not recommended; put it on the fileserver that you were considering using for file://). SVN takes very few system resources, it doesn't need a dedicated system.

rmeador 2009-08-18 14:31:30

@meadow: You're probably right about the term "server". Let me add that it doesn't even require Apache. The `svn:` protocol is fine even without. (The advantage of a virtual machine is that it is easy to move it. That's handy when you don't have enough hardware resources to run a dedicated machine or when you're not allowed to change an existing one.)

sbi 2009-08-19 11:39:13

@rmeador: I agree completely. However, like you said, "set up a server" sets off alarm bells, so the product that I'm developing is designed to run in a server-less environment, in which the only collaboration space is shared disk.

Patrick Linskey 2009-08-19 23:40:05

@Patrick: That sounds so wrong, it borders on stupidity. I bet the product you develop is also designed to run in an environment free of developing tools -- yet I'm sure you will use those. Heck, you're using SO to find a solution to your problem, while I bet this won't be required by the product's users. Just because I'm not bricklaying in my apartment, that doesn't mean the bricklayers were supposed to build it without trowels. In your case, the trowel is a XP/Linux/OSX machine that runs SVN. This could be the very machine your shared disk is on.

sbi 2009-08-20 07:55:52

@sbi: to be clear, I'm considering using svn /in/ the product, not /to build/ the product. We're already happily using git (on http://unfuddle.com, which rocks) for SCM.Our product has specific collaboration needs, and our sales process demands a "server-less" option for our clients, in which there is no separate server process required to enable these features. However, we can rely on an existing CIFS mount (over which we have no control, and our clients are unwilling to assert control). We're considering svn since it is a nice abstraction, and evolves nicely to server-full deployments.

Patrick Linskey 2009-08-20 22:29:54

@Patrick: I didn't understand that SVN was meant to be used _in_ the product. Sorry.

sbi 2009-08-21 09:51:23

+2 A:

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.

Daniel Pryden 2009-08-17 19:23:19

I'm perfectly happy with "dog slow", as it turns out. Even "cat slow" would be ok. Just not "unsafe".I understand that setting up a server is a better approach, but it's not an option for this product, sadly.

Patrick Linskey 2009-08-17 19:29:01

The way we did it on Windows was to use Apache to serve up our files. Here We are very happy with this setup.

JBrooks 2009-08-17 19:27:18

Or you can have a tool do it for you: the VisualSVN server.

reinierpost 2009-10-07 16:25:33

+3 A:

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

aldux 2009-08-17 19:38:22

What sorts of corruption issues did you run into? Were you using BDB or FSFS? What sort of filesystem were you using?

Patrick Linskey 2009-08-17 19:43:14

+9 A:

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

crashmstr 2009-08-17 19:43:55

Interesting... thanks for the link! I wonder what repository corruption issues they're concerned about.

Patrick Linskey 2009-08-17 19:48:18

IIRC, SVN uses files for locking, not actual filesystem-level locks (since they're not uniformly supported across filesystems and operating systems). It's possible for a race condition to exist on a network share because the filesystem operations that are assumed to be atomic (i.e. move) are not guaranteed to be atomic when being accessed over a network. This was explained to me in depth at one point by the SVN devs, but I may have forgotten some details, but I think that's the gist of it.

rmeador 2009-08-17 22:12:50

+3 A:

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.

Peter Parker 2009-08-17 20:56:21

UM, I think there's a difference between FSFS and the `file:` protocol, no?

sbi 2009-08-17 22:08:58

Do you have any support for why corruption won't occur, or is that based on the (probably legit) assumption that the SVN guys would avoid file corruption in any environment?

Patrick Linskey 2009-08-18 00:25:25

As meadows stated: "It's possible for a race condition to exist on a network share because the filesystem operations that are assumed to be atomic (i.e. move) are not guaranteed to be atomic when being accessed over a network.", However I do not have any insight in this issue.

Peter Parker 2009-08-18 02:23:29

ansaurus

tags:

views:

answers:

svn repository on Windows network share

related questions