On Apr 3, 2007, at 17:54, Ed Hillmann wrote:
> On 4/4/07, Viktor Linder wrote:
>> 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+
> I was doing an investigation for work about moving from CVS to SVN.
> Long story short, we have some Perl apps that were using a cvs
> repository to make releases of files, and I was looking at the
> performance impact of moving to SVN. So, this is Perl on a Unix
> As part of this, I compared the same code working against a local
> repository (using the file:// url) with a remote repository (using the
> svn:// url). Note, that the "remote" repository was on the same
> server, just going through the svnserve process. I think (it was some
> time ago).
> The app used svn list, revprop_get, propget and cat commands, and I
> found that the performance was much faster when working against a
> local repository.
I can well imagine that in your scenario, Ed, file-protocol access
will be faster than svn-protocol access, when the repository server
is the same machine as the client. The file access is local to the
machine, while the svn protocol introduces network overhead.
However, that is not Viktor's scenario. He was using the file
protocol to access repositories on a remote server over a Windows
network share, which is not optimized for Subversion communications,
and there may be reliability issues as well when using a network
share for a repository. Using the svn protocol here will likely help
Viktor, since it will be replacing a bad general-purpose network
protocol with a good special-purpose one.
> It may pay to give it a try and see if your mileage varies.
I agree Viktor should test it himself and reach his own conclusions.
To reply to the mailing list, please use your mailer's Reply To All
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Apr 4 03:52:43 2007