Network Drive Support ?

[Phil Pinkerton <pc...@gmail.com>]

Question from a client:

Does Subversion support checking out to a "network drive" many miles away ?

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 )

thanks

Phil


-- 
" The fundamental principle here is that the justification for a
physical concept lies exclusively in its clear and unambiguous
relation to the facts that it can be experienced"   AE

Please Feed and Educate the Children... it's the least any of us can do.

RE: Network Drive Support ?

["Loritsch, Berin" <bl...@dtri.net>]

> From: Phil Pinkerton [mailto:pcpinkerton@gmail.com] 
> 
> Question from a client:
> 
> Does Subversion support checking out to a "network drive" 
> many miles away ?
> 
> 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 )

Think of it this way.  Any network activity is much slower than a local
drive.  A checkout _to_ a remote drive will have many network accesses
for each temp file creation and deletion.  With the current local copy
format for SVN, that is at least two network accesses for each changed
file.  That is why the preferred best practice is to host the code on a
server and check out from the remote machine directly.  The
client/server interactions have been optimized.  To have a machine check
out files to a remote drive will cause all sorts of network activity as
that machine negotiates with the server and the remote drive.  In
Windows operating systems, networked drives are painfully slow when
dealing with many small files.  There are several network interactions
for each file that is created/read/modified on a remote drive--including
DNS lookup, network authentication, checksum validations, etc.

Is this enough to get you started?


Confidentiality Note: The information contained in this message, and any attachments, may contain proprietary and/or privileged material. It is intended solely for the person or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

Re: Network Drive Support ?

[Nico Kadel-Garcia <nk...@gmail.com>]

On Tue, Oct 26, 2010 at 8:46 AM, Phil Pinkerton <pc...@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.