You should NEVER use the file:// protocol unless you are the only
person using the repository, and the repository is only accessible by
The file:// protocol requires read and write permissions on all files
in the repository for the user who is doing the committing. This means
that instead of using Subversion commands, the user can munge the
repository directly. For example, the user could copy the repository,
manipulate the items in it, and then replace it with the munged copy.
Even worse, if user "bob" does a commit, the version file is now owned
by "bob", and if the rights aren't setup correctly, only "bob" might
be able to read and write that version.
I don't know if there are concurrency issues, but I don't even use
file:// when I am creating my own temporary repositories.
I understand why you may not want to use Apache's http as your server.
That can be a bit of a bear to setup. However, the svnserve server is
quick and simple to setup. It is definitely easier to use than shared
Windows directories and affords you full client/server protection.
You should seriously consider not using the file:// protocol.
On Wed, Mar 17, 2010 at 11:30 AM, Jeff Marver <jmarver_at_serlio.com> wrote:
> Hi all,
> We're using SharpSVN.SvnRepositoryClient.CreateRepository to create file:///
> protocol based svn repositories on shared Windows network drives. Can anyone
> tell me the exact permissions a Windows user will need to fully interact
> with the repository? We're recently run into a user that was able to lock a
> file but couldn't do a commit, the error indicated that the commit failed
> and a .tmp file couldn't be moved since it already existed in txn-current?
> The customer indicated that they had read and write access??
> Also, I've seen quite a few posts on the Internet suggesting that sharing a
> file:/// protocol based svn repository is not recommended for multiple users
> and even discouraged. Can anyone confirm or refute this information?
Received on 2010-03-17 22:56:58 CET