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
Received on Tue Jul 26 21:26:08 2005