[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Performance of file:// vs svn://

From: David James <james_at_cs.toronto.edu>
Date: 2007-04-03 18:06:36 CEST

On 4/3/07, Viktor Linder <viktor@grin.se> wrote:
> Hi!
> My company is currently using svn using the file:// protocol on a
> Windows network share. The reason this was chosen was because of the
> simple authentication setup.
> We are experiencing some performance issues, which has caused me to
> investigate if perhaps we should switch to using svnserve or Apache.
>
> Has anyone seen any performance gains using svn:// over file://?
> Our usage scenario is changes to many large binary files for 50+ users.

Hi Viktor,

Based on what I've read on this list, I expect that you will see
substantial performance and reliability improvements if you switch
from file:// access over a Windows network share to svn:// protocol.
The svnserve network server is very easy to setup, and is highly
optimized for remote access.

Unfortunately, I don't think it is ever safe to access Subversion
repositories over a Windows network share. Many users have reported
reliability problems in this scenario. The FSFS backend for Subversion
is designed to be accessed safely over NFS; this same guarantee does
not apply to Windows network shares which have very different
semantics, and have never been officially tested with Subversion.

See http://svn.haxx.se/users/archive-2007-03/0628.shtml for an example
of a Subversion repository which experienced reliability problems due
to being accessed over a Windows network share.

Cheers,

David

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Apr 3 18:07:04 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.