[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: large revision causes problems

From: Jan Evert van Grootheest <j.grootheest_at_euronext.nl>
Date: 2003-09-11 12:21:08 CEST

Hmm, of course I should've reported as well that the server is Apache
2.0.47 on RH 7.3/Advanced Server and SVN is 0.29 (all downloaded from
subversion.tigris.org).
The client is also 0.29.

-- Jan Evert

Jan Evert van Grootheest wrote:

> Hello,
>
> I am having these problems with SubVersion due to a really large
> revision (or two) that's in the repo.
>
> Here's the history:
> There's a tree of files that I once tried to commit. It started to
> transfer the data (printing all those dots), but after a long time it
> reported an error. I think the server committed everything just fine,
> because the tree is there when I browse through it with a web browser.
> However, the client reported an error. Unfortunately, the exact error
> got lost. The WC directory tree for the commit totals some 230Mb.
> The working copy that the committed tree is in, still thinks that the
> add was not committed.
> If I try 'svn status', it reports in 18832 lines things that need to be
> added.
> If I try 'svn status -u' I can see from apache that it does a lot of
> things for a while and then one worker shoots up to 99.x% CPU and stays
> there for a long time. At some point in time, the client reports a timeout:
> [issysd25@a05008 current]$ svn st -u
> svn: RA layer request failed
> svn: REPORT request failed on '/svn/MAL/!svn/vcc/default'
> svn: REPORT of '/svn/MAL/!svn/vcc/default': Error reading chunked
> response body (http://a05009:65030)
> All the while, the server is still very busy. These are the relevant
> lines from the apache access log:
> a05008.aex.nl - - [10/Sep/2003:16:53:30 +0200] "PROPFIND
> /svn/MAL/MAL/Dev/documentation/3rdparty/ACE/current HTTP/1.1" 207 758
> a05008.aex.nl - - [10/Sep/2003:16:53:30 +0200] "PROPFIND
> /svn/MAL/!svn/vcc/default HTTP/1.1" 207 397
> a05008.aex.nl - - [10/Sep/2003:16:53:30 +0200] "PROPFIND
> /svn/MAL/!svn/bln/16 HTTP/1.1" 207 450
> a05008.aex.nl - - [10/Sep/2003:16:53:30 +0200] "PROPFIND
> /svn/MAL/!svn/bc/16/MAL/Dev/documentation/3rdparty/ACE/current HTTP/1.1"
> 207 769
> a05008.aex.nl - - [10/Sep/2003:16:53:30 +0200] "PROPFIND
> /svn/MAL/MAL/Dev/documentation/3rdparty/ACE/current HTTP/1.1" 207 758
> a05008.aex.nl - - [10/Sep/2003:16:53:32 +0200] "PROPFIND
> /svn/MAL/!svn/bc/16/MAL/Dev/documentation/3rdparty/ACE/current/ACE_wrappers
> HTTP/1.1" 207 2802
> a05008.aex.nl - - [10/Sep/2003:16:53:32 +0200] "PROPFIND
> /svn/MAL/!svn/bc/16/MAL/Dev/documentation/3rdparty/ACE/current/ACE_wrappers/html
> HTTP/1.1" 207 11436
> a05008.aex.nl - - [10/Sep/2003:16:53:33 +0200] "PROPFIND
> /svn/MAL/!svn/bc/16/MAL/Dev/documentation/3rdparty/ACE/current/ACE_wrappers/html/tao
> HTTP/1.1" 207 6158346
> a05008.aex.nl - - [10/Sep/2003:16:53:30 +0200] "REPORT
> /svn/MAL/!svn/vcc/default HTTP/1.1" 200 9027147
> Although I cannot guarantee that all these lines are the result of that
> svn status call, the paths in them all relate it. And the number 16 (if
> it is a revision number) matches that really big commit that failed
> client-side that I mentioned above. As you can see, it returns some 15Mb
> in total in the last two lines.
>
> Any comments up till now are welcome.
> As for questions....
> What can I do to make this 'svn status -u' complete (apart from a faster
> server, of course)?
> Will all 'svn status -u' calls in the future have this problem?
>
> What can I do to get this working better? How can I help you to improve
> subversion with regard to this problem? I will not be able to do
> extensive debugging, although investing a limited amount of time is no
> problem.
> I really would like to improve subversion and not expose the rest of the
> company to this, as there are already some that are not convinced of the
> advantages of svn over source safe (from a project point of view, not
> necessarily technical).
> Since, until now, there is no proprietary code in the repo yet, I could
> mail/make available the database or a dump of it for testing. The db is
> some 374Mb, while the zipped dump is still close to 60Mb.
> Processing the dump somewhat reports these numbers:
> [switch@a05009 dump]$ wc -l MAL.20030911
> 7258432 MAL.20030911
> [switch@a05009 dump]$ grep -na Revision-number MAL.20030911
> 5:Revision-number: 0
> 15:Revision-number: 1
> 285:Revision-number: 2
> 1939:Revision-number: 3
> 1966:Revision-number: 4
> 2585:Revision-number: 5
> 3204:Revision-number: 6
> 3806:Revision-number: 7
> 4407:Revision-number: 8
> 5042:Revision-number: 9
> 4743620:Revision-number: 10
> 4743645:Revision-number: 11
> 4743670:Revision-number: 12
> 4743702:Revision-number: 13
> 4743724:Revision-number: 14
> 4746521:Revision-number: 15
> 4746558:Revision-number: 16
>
> Thanks,
> Jan Evert
>
>
>
>
>
> ---------------------------------------------------------------------
> 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 Thu Sep 11 12:22:41 2003

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.