On Fri, Nov 5, 2010 at 2:54 PM, Chris Tashjian <ct...@thepond.com> wrote: > Paul - I'll see if I can get a test repo up with the error. In the > meantime, would a copy of the svn:mergeinfo help?
No harm in sending it along, though barring something very odd I don't hold out much hope it's going to tell us much. > On 11/5/2010 9:59 AM, Paul Burba wrote: >> >> Chris, >> >> I recall a similar issue >> http://subversion.tigris.org/issues/show_bug.cgi?id=3397. >> Unfortunately nothing conclusive came of that. >> >> When I wrap up what I am working on now I will take a look at this. >> In the meantime, any chance you could try to reproduce the problem >> using a simple test repository? No worries if you can't, but >> obviously being able to reproduce the problem on our side would be >> very helpful. >> >> Paul >> >> On Thu, Nov 4, 2010 at 8:59 PM, Chris Tashjian<ct...@thepond.com> wrote: >>> >>> I posted this on the users list, but I'm confident that this is a bug. >>> >>> Background: >>> For a while now (off and on for over a year, but more frequently in the >>> last >>> 6+ months) we've been having problems with svn "crashing", yet there's no >>> error in the log file. In talking to someone the users list it sounds >>> like >>> svn is actually just hanging. Clients get the following response: >>> >>> svn: Can't connect to host 'svn': No connection could be made >>> because the target machine actively refused it. >>> >>> Our repository has 129K revisions. The format is "4 layout linear", it >>> was >>> created with svnadmin 1.4.x and has since had "svnadmin upgrade" run both >>> in >>> 1.5 and 1.6. We're currently running SlikSVN 1.6.13 (Win32), but I have >>> previously had this problem dating back to versions of 1.5, both stock >>> and >>> from CollabNet. The issue now happens numerous times per day and it >>> looks >>> like I've discovered why.... >>> >>> >>> As a test I ran "svn blame -g" on a file with a bunch of revisions and >>> watched memory usage on the server spin up to 2GB. >>> >>> I restarted the server and then tried "svn blame" (no -g) on the same >>> file >>> and it ran quickly, with no major up-tick in memory usage. >>> >>> I tried it again with -g and it blew up to 2GB. >>> >>> Next, (after restarting the server) I tried another file with more >>> revisions. "svn blame" spins memory usage to 45MB and then eventually >>> comes >>> back with output. >>> >>> "svn blame -g" on this same file, causes svnserve to quickly (in about 45 >>> seconds) climb to 2GB of memory usage and doesn't come back (at least >>> after >>> 5 minutes). At that point, I just killed svnserve.exe on the server. >>> >
