Ben Collins-Sussman <sussman@collab.net> wrote:
>> The working copy is a checkout from
>> http://svn.collab.net/repos/svn/trunk/ (I apologize for mentioning
>> svnserve, this was obviously wrong). The bug can easily be
>> reproduced by downloading the following tarball:
>> http://farfetch.intrepid.cx/subversion-1.2-broken.tar.bz2
>> unpacking it, and running "svn up" from within the directory it
>> creates (under Linux).
>
> I downloaded the tarball to windows XP and unpacked it. I don't how
> you managed, but 'svn status' shows every directory being on the
> 1.2.x branch, but every file being on trunk!
Ah thank you. This working copy is the result of having aborted a 'svn switch'
operation. I was switching the working copy from the trunk to the 1.2.x branch,
but it was taking forever and looked to be hanged, so I aborted it through
CTRL+C. Maybe is there something that can be done to avoid this kind of
situation?
> As a result, nearly every object
> in the working copy is reported as 'S' (switched).
> I ran 'svn up' using a win32 svn 1.2.0 client, and as expected it
> took a very long time to describe every single switched object
> to the server... but the update finished successfully in about
> 30 seconds.
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. 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
[....]
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.
- 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 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?
- 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?
- How am I expected to fix my working copy?
Giovanni Bajo
---------------------------------------------------------------------
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:31:21 2005