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

Re: Network Drive Support ?

From: Nico Kadel-Garcia <nkadel_at_gmail.com>
Date: Tue, 26 Oct 2010 22:27:39 -0400

On Tue, Oct 26, 2010 at 8:46 AM, Phil Pinkerton <pcpinkerton_at_gmail.com> wrote:
> Question from a client:
>
> Does Subversion support checking out to a "network drive" many miles away ?

Yes, but the performance can vary tremendously depending on the
network topoloogy and the network drive technology. A CIFS or typical
windows share, for example, is fine for a small branch. But for the
kind of Gigabyte working copies I've been dealing with lately, it's
*horrid* and takes over 30 minutes, even for very capable Subversion
servers in the same building, using svn access. NFS shares take only
three in my particular environment, even

> They are asking due to extremely slow checkouts across a WAN to a NAS
> drive. I need a technical answer with regards to the performance of
> subversion in this scenario. ( as if speaking to a 10 year old ...mgmt
> haha )

See above. One workaround is to keep a working copy nightly updated
from the trunk, do an ordinary CIFS copy, and do "svn update" or "svn
switch" to branches with that working copy as necessary. This is what
I know some people are doing. Others have switched to Linux to use NFS
shares, which take only 3 minutes for the same operation.

Subversion does many things well, and it's a popular tool, partly due
to its well understood, centralized management. For CIFS checkouts of
large working copies, other technologies (like git) kick its tail. And
for being able to do local checkins of updates and only push changes
to a master copy as desired, git is far superior. And the ability to
GPG sign tags makes up in mahy ways, for the less centralized
management.
Received on 2010-10-27 04:28:14 CEST

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.