Giovanni Bajo wrote:
> So it appears to be just very slow. I let it go and this is the result:
>
> real 6m9.907s
> user 0m1.683s
> sys 0m0.825s
>
> 6 minutes is really a long time and SVN absolutely provides *no* feedback at
> all during 99% of this time.
That's because update and switch commands walk over the working copy and
report revisions/paths to the server. In your pathological case, the
client must report *every* object in your tree to the server. That's
what's taking so long.
Just at the very end it starts listing the files
> being updated:
>
> A www/logo/subversion_logo.svg
> A www/images/svn-dav-securityspace-survey-2002_12-2005_02.png
> D www/project_footer.html
> [....]
Right. Once the server receives the description of the working copy, it
begins to send changes. It does this by comparing the latest revision
with your working copy description.
>
> I have thus some questions:
>
> - Does your win32 SVN client promptly aborts when you send a CTRL+C? The Linux
> client seems to totally ignore the signal. I heard many of these problems have
> fixed in 1.2.0 but in this case probably some work remains to be done.
>
The problem is with neon, the library used by the svn client to do http
requests. Normally, svn traps SIGINT and polls for the interrupt. But
due to a neon bug, control-c causes neon to read all data from the
network without giving svn any control.
The bug is fixed in the newest neon release (0.25), and we're working on
making it work with svn now. Expect to see neon 0.25 in svn 1.3.
> - I wonder why there is such a difference in time of execution. I do not think
> one should expect a "svn up" command to take more than 6 minutes to finish
I have no explanation as to why it takes 6 minutes for you and 30
seconds for me. Perhaps I'm simply closer to svn.collab.net?
>(I
> have a regular broadband connection). Can some kind of feedback be provided to
> show that SVN is actually working? Does the 'switch' operation causes operation
> time of SVN to always increase so much or is it just my unfortunate working
> copy?
Yes, when many things are 'switched', the client has more information to
report to the server than normal. Still, it would be interesting for
you do to a completely new 'svn checkout' of the branch, and then time
how long it takes to 'svn up' the working copy.
>
> - I would expect that, whatever situation my working copy was in, the working
> copy would be fixed after the first 'svn up' completed. So I ran another 'svn
> up' after the first one, and this is not true: it is still taking forever, and
> this time 10 minutes are already passed... Why doesn't 'svn up' fix this weird
> stiuation?
There's nothing broken to fix. You have an extremely complex working
copy: it's full of switched files. 'svn update' merely gets the latest
versions of everything, it doesn't remove the 'switched-ness'. To do
that, you need to 'svn switch branchURL'. That's the only way to put
everything back on the same branch.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jun 1 04:39:49 2005