You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Jeff Lasslett <je...@datataker.com.au> on 2004/04/19 02:13:23 UTC
Probs with working dir on net shared drive
Hi,
My working directory is on a drive on another PC on my LAN. This is because I
have just one licence for my compiler and it is tied to the hardware it was
installed on. There are two developers. Both of us check out our source code
to this third PC and compile there. The problem is that checking out to this
network share is slow and error prone.
We are using MS Windows (2000 pro) and subversion 1.0 with apache. The
subversion repository and apache are running on my PC (for the moment). When I
check out or update my source tree to my work area, the operation proceeds in
spurts and eventually stops indicating that a file already exists and it can't
be copied over. I can usually delete the offending file from my work area and
use the clean feature to remove locks. I can then restart the process. I
repeat these step a few times and eventually I have a complete set of sources to
work with.
I updated the network adapter (to 100 Mbit) in the PC where my working
directory is and this did improve the situation. Instead of cleaning and
restarting 10s of times, I only need to do it a few times.
I have installed subversion and tortoiseSVN on the machine containing the
network drive. A checkout operation initiated on this latter machine, to the
working area specified as a local dir (not using the network drive letter
mapping) completes successfully. The same operation where the working directory
is specified in terms of its network drive letter mapping, has problems.
Namely:-
"Can't move
'W:/svn_working_v4/jeff/src/PC_SUPPORT/UserUpgradeControl/.svn/tmp/entries'
to
'W:/svn_working_v4/jeff/src/PC_SUPPORT/UserUpgradeControl/.svn/entries'
Can't create a file when that file already exists."
To summarise: checking out to a working area specified in terms of a network
drive letter mapping is dodgy (for me here at least).
Is this a known bug? Any insights, work-arounds, comments etc would be greatly
appreciated.
Thanks and Cheers,
Jeff
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Probs with working dir on net shared drive
Posted by Ulrich Eckhardt <ec...@satorlaser.com>.
Jeff Lasslett wrote:
> There are two developers. Both of us check
> out our source code to this third PC and compile there. The problem is
> that checking out to this network share is slow and error prone.
I'm not sure if that is the case, but are you running svn locally to check out
a working copy that is then transparently stored on a remote machine? If so,
you would save lots of overhead by running svn on the remote machine
directly.
Uli
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Probs with working dir on net shared drive
Posted by John Peacock <jp...@rowman.com>.
Jeff Lasslett wrote:
>> It's also possible that the network delays are making the existing Win
>> filesystem race conditions worse.
>
>
> There are race conditions within the NTFS code that are known about
> publicly?
Yes. Win32 services can install hooks at file creation and access (think
Antivirus software) which will cause the creation and immediate deletion of lots
of small files to be extremely slowed. Additionally, it is impossible under
NTFS to delete an open file (which another process has still open). Under more
sane filesystems, an open file can be deleted by one process and the filesystem
will get around to it when the other process closes its filehandle.
There is specific code in the Subversion source which will retry certain delete
operations for this very reason. For testing purposes, you might try disabling
the AV software (either completely or just exclude certain directories). Be
aware that for some AV software, excluding folders is not enough; the CVSNT
project has documented cases where AV software will still hook the file access
(but just skip the scan) even when excluded. In those instances, stopping the
service that manages on-access or even uninstalling was required for good
performance.
HTH
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Probs with working dir on net shared drive
Posted by Jeff Lasslett <je...@datataker.com.au>.
Branko Čibej wrote:
> It's not a Subversion bug. There's not much SVN can do if you have a
> flaky network connection or file server.
Fair enough. However there is no *known* flakiness with either of the machines
involved, or the network. Bear in mind that checkouts work fine if I'm sitting
at the file server and I don't use the network drive mapping. If I'm at my
workstation though, then it would be nice if I could checkout to the fileserver,
and to do that I need to use the network drive mapping.
> It's also possible that the
> network delays are making the existing Win filesystem race conditions
> worse.
There are race conditions within the NTFS code that are known about publicly?
> You say both your repository server and your file server are
> Win2k machines. What kind of filesystem are you using?
NTFS.
Cheers,
Jeff
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Probs with working dir on net shared drive
Posted by Branko Čibej <br...@xbc.nu>.
Jeff Lasslett wrote:
> Hi,
>
> My working directory is on a drive on another PC on my LAN. This
> is because I have just one licence for my compiler and it is tied to
> the hardware it was installed on. There are two developers. Both of
> us check out our source code to this third PC and compile there. The
> problem is that checking out to this network share is slow and error
> prone.
>
> We are using MS Windows (2000 pro) and subversion 1.0 with
> apache. The subversion repository and apache are running on my PC
> (for the moment). When I check out or update my source tree to my
> work area, the operation proceeds in spurts and eventually stops
> indicating that a file already exists and it can't be copied over. I
> can usually delete the offending file from my work area and use the
> clean feature to remove locks. I can then restart the process. I
> repeat these step a few times and eventually I have a complete set of
> sources to work with.
>
> I updated the network adapter (to 100 Mbit) in the PC where my
> working directory is and this did improve the situation. Instead of
> cleaning and restarting 10s of times, I only need to do it a few times.
>
> I have installed subversion and tortoiseSVN on the machine
> containing the network drive. A checkout operation initiated on this
> latter machine, to the working area specified as a local dir (not
> using the network drive letter mapping) completes successfully. The
> same operation where the working directory is specified in terms of
> its network drive letter mapping, has problems.
> Namely:-
>
> "Can't move
> 'W:/svn_working_v4/jeff/src/PC_SUPPORT/UserUpgradeControl/.svn/tmp/entries'
>
> to
> 'W:/svn_working_v4/jeff/src/PC_SUPPORT/UserUpgradeControl/.svn/entries'
> Can't create a file when that file already exists."
>
> To summarise: checking out to a working area specified in terms of a
> network drive letter mapping is dodgy (for me here at least).
>
> Is this a known bug? Any insights, work-arounds, comments etc would
> be greatly appreciated.
It's not a Subversion bug. There's not much SVN can do if you have a
flaky network connection or file server. It's also possible that the
network delays are making the existing Win filesystem race conditions
worse. You say both your repository server and your file server are
Win2k machines. What kind of filesystem are you using?
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org