You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by jason marshall <jd...@gmail.com> on 2005/07/26 18:06:41 UTC
svn up known issue?
We have a very large code repository that we've been evaluating with
Subversion. It's very sluggish, unacceptably so, but that's not the
particular issue I'd like to address.
What I wish to discuss is that 'svn up' doesn't clean up after itself
if user authentication times out. I have verified this behavior under
1.1.4 and 1.2.1 on Windows XP.
We are retrieving files via svn+ssh, from an FSFS repository on our
LAN. 'svn up' takes a good ten minutes (and 60M of memory) to run
before it finally asks for my password. What it's doing during this
time period, I cannot say, but it's surely not economizing on human
time by doing so. If I should unsurprisingly get bored or step away
from my computer, I may miss this prompt. At this point the clock is
ticking before the connection is lost, and by the time I type in my
password, it may be too late. In this case, I get a "Connection
closed unexpectedly" error, and running 'svn up' again tells me that:
svn: Working copy '.' locked
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
In which case svn cleanup can take another 20 minutes to run
(consuming 100M of memory), after which I can look forward to another
10 minutes of twiddling before I can run update again.
--
-Jason
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn up known issue?
Posted by jason marshall <jd...@gmail.com>.
On 7/26/05, Hari Kodungallur <hk...@gmail.com> wrote:
> On 7/26/05, jason marshall <jd...@gmail.com> wrote:
> >
> > What do you consider to be 'quite acceptable'? I don't consider a 20
> > minute cleanup to be that. How long does a full update take? I
> > clocked a small one (20 files) at just under 10 minutes. It still
> > seems to me like a cleanup should be faster than an update, but I lack
> > insight into just what a cleanup does.
> >
>
> On our linux box, a repository that is more than 1GB (don't know exact
> number of files, but it is in tens of thousands) takes about 45
> minutes to checkout. Similar numbers for update and this number is
> fairly typical with most of the subversion users, I think.
> So, if it takes 10 minutes to update 20 files, I think there is
> something else in your setup that is not right. (or each file is a
> humungous binary file or something)
No, I meant that in a large repository (750M, tens of thousands of
files), svn up took 10 minutes, and found that 20 files on the server
had been modified. I believe that at other times it has taken longer
than that, but I don't have firm numbers there.
>
> rgds
> -Hari
>
--
-Jason
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn up known issue?
Posted by Hari Kodungallur <hk...@gmail.com>.
On 7/26/05, jason marshall <jd...@gmail.com> wrote:
>
> What do you consider to be 'quite acceptable'? I don't consider a 20
> minute cleanup to be that. How long does a full update take? I
> clocked a small one (20 files) at just under 10 minutes. It still
> seems to me like a cleanup should be faster than an update, but I lack
> insight into just what a cleanup does.
>
On our linux box, a repository that is more than 1GB (don't know exact
number of files, but it is in tens of thousands) takes about 45
minutes to checkout. Similar numbers for update and this number is
fairly typical with most of the subversion users, I think.
So, if it takes 10 minutes to update 20 files, I think there is
something else in your setup that is not right. (or each file is a
humungous binary file or something)
rgds
-Hari
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn up known issue?
Posted by Gary Thomas <ga...@mlbassoc.com>.
On Tue, 2005-07-26 at 21:41 -0700, jason marshall wrote:
> On 7/26/05, Gary Thomas <ga...@mlbassoc.com> wrote:
> > On Tue, 2005-07-26 at 14:18 -0700, jason marshall wrote:
> > ... snip
> > > I encourage the SVN team to reassess their definition of 'reasonable
> > > working set', and consider if the tool as currently presented can meet
> > > reasonable performance metrics given that definition.
> >
> > What do you consider a "ridiculously large" working copy?
> > I routinely work with branches that have nearly 50,000 files in
> > them (totalling over 1GB) and find the performance of subversion
> > quite acceptable.
>
> What do you consider to be 'quite acceptable'? I don't consider a 20
> minute cleanup to be that. How long does a full update take? I
> clocked a small one (20 files) at just under 10 minutes. It still
> seems to me like a cleanup should be faster than an update, but I lack
> insight into just what a cleanup does.
>
> That's about what I would consider to be Very Large, which is about
> the size of this tree. I wasn't the one who characterized it as
> ridiculously large, hence my insistence that it wasn't. If our
> definitions line up, but our experiences don't, then that would
> suggest misconfiguration of our server, which is entirely possible.
>
Here are some times for comparison:
% time svn co URL
real 15m38.719s
user 1m57.410s
sys 0m53.381s
[main-dir]$ time find . -type f | grep -v .svn | wc
43780 43780 2392619
real 5m50.013s
user 5m33.805s
sys 0m2.709s
[main-dir]$ time svn up
At revision 1499.
real 4m20.819s
user 0m10.959s
sys 0m1.750s
In one sub-directory:
[sub-dir]$ time svn up
At revision 1499.
real 0m5.257s
user 0m0.167s
sys 0m0.097s
[sub-dir]$ time svn cleanup
real 0m3.403s
user 0m0.169s
sys 0m0.249s
[sub-dir]$ time find . -type f | grep -v .svn | wc
909 909 34761
real 0m12.131s
user 0m11.688s
sys 0m0.077s
As you can see, subversion can walk the tree and perform operations
like 'update' at least as fast as a simple command to just enumerate
the files! Also, the times truly aren't bad for a 44,000 file tree.
Note: these particular times are on Linux 2.6, running on a Mac Mini.
The file system is 'ext3'. It's a reasonably fast box, but certainly
not the fastest one I have here.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn up known issue?
Posted by jason marshall <jd...@gmail.com>.
On 7/26/05, Gary Thomas <ga...@mlbassoc.com> wrote:
> On Tue, 2005-07-26 at 14:18 -0700, jason marshall wrote:
> ... snip
> > I encourage the SVN team to reassess their definition of 'reasonable
> > working set', and consider if the tool as currently presented can meet
> > reasonable performance metrics given that definition.
>
> What do you consider a "ridiculously large" working copy?
> I routinely work with branches that have nearly 50,000 files in
> them (totalling over 1GB) and find the performance of subversion
> quite acceptable.
What do you consider to be 'quite acceptable'? I don't consider a 20
minute cleanup to be that. How long does a full update take? I
clocked a small one (20 files) at just under 10 minutes. It still
seems to me like a cleanup should be faster than an update, but I lack
insight into just what a cleanup does.
That's about what I would consider to be Very Large, which is about
the size of this tree. I wasn't the one who characterized it as
ridiculously large, hence my insistence that it wasn't. If our
definitions line up, but our experiences don't, then that would
suggest misconfiguration of our server, which is entirely possible.
>
> Of course, things do run much faster if I can pick out only the
> pieces I'm interested in (which is made much easier by a great
> tool like subversion!)
That's true, but the coordination effort is higher, and the chance for
angst is higher as well.
I like to have my tools do what tools can do, and the humans do
everything else. Keeping files synchronized? That's a tool's job.
>
> --
> ------------------------------------------------------------
> Gary Thomas | Consulting for the
> MLB Associates | Embedded world
> ------------------------------------------------------------
>
>
--
-Jason
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn up known issue?
Posted by Gary Thomas <ga...@mlbassoc.com>.
On Tue, 2005-07-26 at 14:18 -0700, jason marshall wrote:
... snip
> I encourage the SVN team to reassess their definition of 'reasonable
> working set', and consider if the tool as currently presented can meet
> reasonable performance metrics given that definition.
What do you consider a "ridiculously large" working copy?
I routinely work with branches that have nearly 50,000 files in
them (totalling over 1GB) and find the performance of subversion
quite acceptable.
Of course, things do run much faster if I can pick out only the
pieces I'm interested in (which is made much easier by a great
tool like subversion!)
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn up known issue?
Posted by John Waycott <ja...@cox.net>.
jason marshall wrote:
>>Perhaps you could tell us exactly how many files and dirs are in your
>>working copy. And, is this running on NTFS?
>>
>>
>
>Certainly. I'll have to poll my non-Windows coworkers for performance
>numbers, but I believe that I am using an NTFS partition (mostly
>defragmented, 25% full). The code tree, minus SVN's additions, is
>about 750 MB and several tens of thousands of files (I can be more
>specific if you need).
>
>Is NTFS really so much worse than FAT32, or are you making a
>comparison versus ext3?
>
>
>
We found that running Norton Antivirus was really slowing things down
during checkout. Turning off the "realtime protection" more than doubled
the checkout speed of a 4,000 file repository from about 5 min to 2 min.
If you are running antivirus software, try turning it off and see what
happens. We didn't test this for update though, so it may not make a
difference.
-- John Waycott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn up known issue?
Posted by jason marshall <jd...@gmail.com>.
find -name .svn | wc -l
6429
That's higher than I would have guessed.
Do you have any suggestions for a more conservative crippling of
antivirus software?
Adding .svn to the extension exclusions list seems to have had some
effect, but then I've noticed a a big standard deviation in my
results, so it's difficult to say if things are better.
-Jason
On 7/27/05, Ben Collins-Sussman <su...@collab.net> wrote:
>
> On Jul 26, 2005, at 11:58 PM, jason marshall wrote:
> > The code tree, minus SVN's additions, is
> > about 750 MB and several tens of thousands of files
>
> How many directories? That's the big factor here. I'd like to know
> how many .svn/entries files are being parsed into memory.
>
>
--
-Jason
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn up known issue?
Posted by Ben Collins-Sussman <su...@collab.net>.
On Jul 26, 2005, at 11:58 PM, jason marshall wrote:
> The code tree, minus SVN's additions, is
> about 750 MB and several tens of thousands of files
How many directories? That's the big factor here. I'd like to know
how many .svn/entries files are being parsed into memory.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn up known issue?
Posted by jason marshall <jd...@gmail.com>.
On 7/26/05, Ben Collins-Sussman <su...@collab.net> wrote:
> jason marshall wrote:
>
> > If the manual labor of using SVN is
> > truly so high, then my recommendation will be to pay the licensing fee
> > for Perforce, as the total cost/benefit is lower, and the in-house
> > expertise is slightly better (a couple of developers, versus none).
>
> Perforce may definitely be a better choice. It's designed to work best
> over a LAN. Users have to tell the server they're about to edit
> something, so the server is 'tracking' every working copy in existence.
> The payoff is that perforce can instantly know which files have
> changed, and the version of every file. It makes all the "discovery
> crawls" done by 'svn up' and 'svn commit' unnecessary. Of course, the
> tradeoff is that you always need to have the server close at hand, for
> absolutely every operation.
Perforce can tell me what Tom, Dick, and Harry are up to by keeping
the user connected. That much is true, and in some situations useful
in its own right, such as when I'm starting a long change, and want to
know if someone else is going to make my life difficult by changing
the file underneath me.
However, you don't strictly need the server in order to have your
local copy be able to tell you what you have open for edit. You could
have a purely local 'checkout' command that served this function. I
would presume that it was instead a desire to avoid explicit file
checkout that requires the full directory scan. One could have
checkouts without the functionality of sharing checkout status with
anyone else. Whether SVN could have such a feature tacked on at such
a late date is another matter entirely, but -some- version control
tool certainly could do so.
> > I encourage the SVN team to reassess their definition of 'reasonable
> > working set', and consider if the tool as currently presented can meet
> > reasonable performance metrics given that definition.
>
> Perhaps you could tell us exactly how many files and dirs are in your
> working copy. And, is this running on NTFS?
Certainly. I'll have to poll my non-Windows coworkers for performance
numbers, but I believe that I am using an NTFS partition (mostly
defragmented, 25% full). The code tree, minus SVN's additions, is
about 750 MB and several tens of thousands of files (I can be more
specific if you need).
Is NTFS really so much worse than FAT32, or are you making a
comparison versus ext3?
--
-Jason
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn up known issue?
Posted by Ben Collins-Sussman <su...@collab.net>.
jason marshall wrote:
> If the manual labor of using SVN is
> truly so high, then my recommendation will be to pay the licensing fee
> for Perforce, as the total cost/benefit is lower, and the in-house
> expertise is slightly better (a couple of developers, versus none).
Perforce may definitely be a better choice. It's designed to work best
over a LAN. Users have to tell the server they're about to edit
something, so the server is 'tracking' every working copy in existence.
The payoff is that perforce can instantly know which files have
changed, and the version of every file. It makes all the "discovery
crawls" done by 'svn up' and 'svn commit' unnecessary. Of course, the
tradeoff is that you always need to have the server close at hand, for
absolutely every operation.
> I encourage the SVN team to reassess their definition of 'reasonable
> working set', and consider if the tool as currently presented can meet
> reasonable performance metrics given that definition.
Perhaps you could tell us exactly how many files and dirs are in your
working copy. And, is this running on NTFS?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn up known issue?
Posted by jason marshall <jd...@gmail.com>.
Ben,
Thanks for the reply. Before I respond to your comments, I wanted
to reiterate that my primary concern is that svn up clean up after
itself if a network error happens at certain 'clean' stages of the
update process, such as before the server is first contacted. The
rest is largely incidental.
On 7/26/05, Ben Collins-Sussman <su...@collab.net> wrote:
>
> On Jul 26, 2005, at 1:06 PM, jason marshall wrote:
> >
> > We are retrieving files via svn+ssh, from an FSFS repository on our
> > LAN. 'svn up' takes a good ten minutes (and 60M of memory) to run
> > before it finally asks for my password. What it's doing during this
> > time period, I cannot say,
>
> It's crawling over every directory in your working-copy tree, loading
> the .svn/entries file into memory, then describing the revision of
> each file to the server. It's also dropping a lockfile into
> each .svn/ area, to prevent other svn clients from changing the
> working copy.
>
> Once that's all done, the server has a 'snapshot' of your working-
> copy which it then compares to the latest revision. The server then
> sends back a tree-delta which the client applies.
Okay, and this is the point at which it figures out that it can't
contact the server, yes?
> > If I should unsurprisingly get bored or step away
> > from my computer, I may miss this prompt. At this point the clock is
> > ticking before the connection is lost, and by the time I type in my
> > password, it may be too late.
>
> That's ssh prompting you, not svn. There must be a parameter
> somewhere to tell sshd not to time out. (Subversion certainly has
> that for its own prompting.)
Right, I appreciate that. This was by way of introduction to the
steps leading up to the actual problem...
> > In this case, I get a "Connection
> > closed unexpectedly" error, and running 'svn up' again tells me that:
> >
>
> The ssh daemon cut you off.
>
Which is that SVN leaves its toys on the proverbial stairs. I suspect
that the same would happen if the server was unreachable.
> > svn: Working copy '.' locked
> > svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for
> > details)
> Hm, if the connection is forcibly closed in the middle of an update
> (or any network error happens), I think the subversion client could
> do better. It should be able to notice and do 'cleanup' itself.
I would think that the reason that teardown takes twice as long as
setup in this case is that 'cleanup' does substantially more than
simply removing locks from the directory tree, right? If so it would
certainly be helpful if svn could take some shortcuts at this point to
tidy up efficiently. If not, then I would much appreciate it if the
cleanup code could be made a bit more efficient.
> > In which case svn cleanup can take another 20 minutes to run
>
> And that's because it's going through each .svn/ area again, removing
> all the lockfiles it left behind.
>
> All that said, you've got many cards stacked against you here.
> You're in the worst of all possible worlds:
Indeed.
> * the svn client does a *lot* of processing of small files in
> the .svn/ area. NTFS is particularly slow at this sort of thing. On
> average, disk-intensive svn client operations typically take 2x as
> long on Windows than on Unix.
> * you have ridiculously large working copy. Nearly every common
> svn client command -- 'update', 'commit', 'status', etc. -- involves
> recursively walking the working copy to discover things. (Update
> needs to discover the version of each file; commit and status need
> to discover which files have changed.)
We do have a ridiculously large working copy, but that's by pure
coincidence. It so happens that we hope to use Subversion to more
simply extract a good number of dead subtrees. I'm confident that, as
you say, our performance will be greatly improved by doing so.
However, as code trees go, this is not by any means a ridiculously
large one. What is in our tree at this moment may be ridiculous, but
I would consider our code tree to be only slightly larger and more
complex than reasonable for a serious, longterm software project.
There will be many companies out there with code trees within a factor
of two of this one. Older companies are likely to have even bigger
trees.
Even Batik, which we used at one point in our testing, is about a
fifth of the size of our tree. How big is the Linux Kernel? JBoss?
Gnome? The Enterprise management system at any multinational company?
> The best answer here is: "Don't Do That."
"Doctor, it hurts when I bend over!"
I'm sure you're trying to be helpful, and I'm sure these suggestions
will make me more productive, but I hope you realise that this is, at
best, a bandaid. I shouldn't have to bend over backward to keep my
tools from exploding in my face. If the manual labor of using SVN is
truly so high, then my recommendation will be to pay the licensing fee
for Perforce, as the total cost/benefit is lower, and the in-house
expertise is slightly better (a couple of developers, versus none).
> Work with smaller pieces of the working copy. Either check out smaller subsets of the
> project, or be *selective* about how you run these commands. Don't
> just run 'svn up' from the top of Mount Everest; cd down into some
> sub-area that you're working on, and run update from there. (Or run
> 'svn up some\sub\area\'.) This will also stop the client from using
> so much memory when it caches 5.89824e37 .svn/entries files.
I have always considered one of the biggest benefits of SCM software
to be as an aid to repeatability. That two developers, across space
and time, can be more or less assured that they should be seeing the
same bug- and feature-set in their code is what allows us to keep
progressing despite increasing team sizes. Cherry-picking subtrees
from a large body of code does little to nothing for repeatability.
I encourage the SVN team to reassess their definition of 'reasonable
working set', and consider if the tool as currently presented can meet
reasonable performance metrics given that definition.
Thank you,
-Jason
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn up known issue?
Posted by Ben Collins-Sussman <su...@collab.net>.
On Jul 26, 2005, at 2:23 PM, Jake Robb wrote:
> You might also consider using a GUI client (like TortoiseSVN on
> Windows),
> which can remember your password and submit it immediately and
> automatically
> when prompted.
>
He's using svn+ssh://, which means nothing can cache the password but
an ssh-caching tool. No subversion client can help, because it's not
subversion doing the authentication. On Windows, he'll need
something like 'pageant'.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: svn up known issue?
Posted by Jake Robb <ja...@mac.com>.
You might also consider using a GUI client (like TortoiseSVN on Windows),
which can remember your password and submit it immediately and automatically
when prompted.
-Jake
-----Original Message-----
From: Ben Collins-Sussman [mailto:sussman@collab.net]
Sent: Tuesday, July 26, 2005 3:16 PM
To: jason marshall
Cc: users@subversion.tigris.org
Subject: Re: svn up known issue?
On Jul 26, 2005, at 1:06 PM, jason marshall wrote:
>
> We are retrieving files via svn+ssh, from an FSFS repository on our
> LAN. 'svn up' takes a good ten minutes (and 60M of memory) to run
> before it finally asks for my password. What it's doing during this
> time period, I cannot say,
It's crawling over every directory in your working-copy tree, loading
the .svn/entries file into memory, then describing the revision of
each file to the server. It's also dropping a lockfile into
each .svn/ area, to prevent other svn clients from changing the
working copy.
Once that's all done, the server has a 'snapshot' of your working-
copy which it then compares to the latest revision. The server then
sends back a tree-delta which the client applies.
> If I should unsurprisingly get bored or step away
> from my computer, I may miss this prompt. At this point the clock is
> ticking before the connection is lost, and by the time I type in my
> password, it may be too late.
That's ssh prompting you, not svn. There must be a parameter
somewhere to tell sshd not to time out. (Subversion certainly has
that for its own prompting.)
> In this case, I get a "Connection
> closed unexpectedly" error, and running 'svn up' again tells me that:
>
The ssh daemon cut you off.
> svn: Working copy '.' locked
> svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for
> details)
>
Hm, if the connection is forcibly closed in the middle of an update
(or any network error happens), I think the subversion client could
do better. It should be able to notice and do 'cleanup' itself.
> In which case svn cleanup can take another 20 minutes to run
And that's because it's going through each .svn/ area again, removing
all the lockfiles it left behind.
All that said, you've got many cards stacked against you here.
You're in the worst of all possible worlds:
* the svn client does a *lot* of processing of small files in
the .svn/ area. NTFS is particularly slow at this sort of thing. On
average, disk-intensive svn client operations typically take 2x as
long on Windows than on Unix.
* you have ridiculously large working copy. Nearly every common
svn client command -- 'update', 'commit', 'status', etc. -- involves
recursively walking the working copy to discover things. (Update
needs to discover the version of each file; commit and status need
to discover which files have changed.)
The best answer here is: "Don't Do That." Work with smaller pieces
of the working copy. Either check out smaller subsets of the
project, or be *selective* about how you run these commands. Don't
just run 'svn up' from the top of Mount Everest; cd down into some
sub-area that you're working on, and run update from there. (Or run
'svn up some\sub\area\'.) This will also stop the client from using
so much memory when it caches 5.89824e37 .svn/entries files.
Hope this helps.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn up known issue?
Posted by Ben Collins-Sussman <su...@collab.net>.
On Jul 26, 2005, at 1:06 PM, jason marshall wrote:
>
> We are retrieving files via svn+ssh, from an FSFS repository on our
> LAN. 'svn up' takes a good ten minutes (and 60M of memory) to run
> before it finally asks for my password. What it's doing during this
> time period, I cannot say,
It's crawling over every directory in your working-copy tree, loading
the .svn/entries file into memory, then describing the revision of
each file to the server. It's also dropping a lockfile into
each .svn/ area, to prevent other svn clients from changing the
working copy.
Once that's all done, the server has a 'snapshot' of your working-
copy which it then compares to the latest revision. The server then
sends back a tree-delta which the client applies.
> If I should unsurprisingly get bored or step away
> from my computer, I may miss this prompt. At this point the clock is
> ticking before the connection is lost, and by the time I type in my
> password, it may be too late.
That's ssh prompting you, not svn. There must be a parameter
somewhere to tell sshd not to time out. (Subversion certainly has
that for its own prompting.)
> In this case, I get a "Connection
> closed unexpectedly" error, and running 'svn up' again tells me that:
>
The ssh daemon cut you off.
> svn: Working copy '.' locked
> svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for
> details)
>
Hm, if the connection is forcibly closed in the middle of an update
(or any network error happens), I think the subversion client could
do better. It should be able to notice and do 'cleanup' itself.
> In which case svn cleanup can take another 20 minutes to run
And that's because it's going through each .svn/ area again, removing
all the lockfiles it left behind.
All that said, you've got many cards stacked against you here.
You're in the worst of all possible worlds:
* the svn client does a *lot* of processing of small files in
the .svn/ area. NTFS is particularly slow at this sort of thing. On
average, disk-intensive svn client operations typically take 2x as
long on Windows than on Unix.
* you have ridiculously large working copy. Nearly every common
svn client command -- 'update', 'commit', 'status', etc. -- involves
recursively walking the working copy to discover things. (Update
needs to discover the version of each file; commit and status need
to discover which files have changed.)
The best answer here is: "Don't Do That." Work with smaller pieces
of the working copy. Either check out smaller subsets of the
project, or be *selective* about how you run these commands. Don't
just run 'svn up' from the top of Mount Everest; cd down into some
sub-area that you're working on, and run update from there. (Or run
'svn up some\sub\area\'.) This will also stop the client from using
so much memory when it caches 5.89824e37 .svn/entries files.
Hope this helps.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org