Can file based SVN repository support simultaneous multi-user situation?

Question

If multiple users accesses file based SVN repository to commit many things simultaneously, can SVN guarantee data integrity? If it is, how? Or if it isn't what serving method should I use for multi-user situation?

Answer 1

Subversion commits are designed to be atomic. Multiple users committing the same revision number at the same time should therefore be impossible. From the subversion book:

An svn commit operation publishes changes to any number of files and directories as a single atomic transaction. In your working copy, you can change files' contents; create, delete, rename, and copy files and directories; and then commit a complete set of changes as an atomic transaction.

By atomic transaction, we mean simply this: either all of the changes happen in the repository, or none of them happens. Subversion tries to retain this atomicity in the face of program crashes, system crashes, network problems, and other users' actions.

Each time the repository accepts a commit, this creates a new state of the filesystem tree, called a revision. Each revision is assigned a unique natural number, one greater than the number of the previous revision. The initial revision of a freshly created repository is numbered 0 and consists of nothing but an empty root directory.

Answer 2

From the Subversion book:

A Subversion repository can be accessed simultaneously by clients running on the same machine on which the repository resides using URLs carrying the file:// scheme. But the typical Subversion setup involves a single server machine being accessed from clients on computers all over the office—or, perhaps, all over the world.

There are several issues with the file:// scheme:

• It has to be on the same server. There are people who put the repository on a Windows share or a NFS drive, then have people mount the share and use the file:// scheme. This will not work. It must be on the same machine in order for the file:// access scheme to work.
• It is unsafe. This is the biggest issue. All users must have read/write permission on the files in the repository which means someone can delete the repository or futz around with the files behind Subversion's back.
• Using svn:// and http:// isn't all that hard to setup. I use Subversion as my own personal version control system, and I use the svn:// scheme. Subversion with http:// is slightly more involved, but I can reliably do it in about an hour.

Answer 3

Just to share my past experience.

My company had a project hosted on SVN. Originally the development team used file:// protocol to access a repository on a SMB shared volume. Honestly it seems working fine. However the performance is simply terrible. When I say terrible, it is like spending minutes for an update/commit. Moreover, I think you can see similar statement from different sources or reference: file:// protocol aimed only for single user access in local machine.

When I get involved in the project, I immediately change to use svnserve for ad-hoc strategy of multi-user access (Although I personally use http for other svn repositories administrated by me). We immediately saw performance improvement in order of magnitude. The extra time for the setup is simply 2 minutes (as we have a server that I can simply start svnserve in console mode and leave it running). Unless you really really cannot arrange any machine to run svnserve/apache, I cannot see any reason to stick to file:// protocol for multi-user access.