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

Re: svn checkout hanging

From: Ryan Schmidt <subversion-2005_at_ryandesign.com>
Date: 2005-11-17 21:24:30 CET

On Nov 17, 2005, at 19:05, Heitzso wrote:

> I converted 4 cvs repositories over to svn.
> Repositories are on linux. I used cvs2svn for the
> conversion and am using fsfs for the backend.
> I can then checkout all of these repositories
> very quickly w/ no hang to another Linux box.
> I'm accessing the repositories via svn://blat/blat
> I then installed svnX on an OS X box I have and
> tried to checkout one of my projects. That hung.
> Afterwards trying to checkout a repository to any
> of my other systems would eventually work, but
> could take 5 or 10 or 20 minutes (or never?) before
> finally starting the process of checking out the
> project.

Sounds like a problem with the Subversion server.

> While a checkout was hanging, I could go to
> another box that had a working directory already
> checked out and run "svn status" against the tree
> and have it return right away.

svn status is an entirely local operating (unlike in CVS) so since
we're talking about a server problem, there's no reason a totally
client operation shouldn't be fast.

> This hanging behavior didn't stop until after I
> completely shutdown OS X and restarted svnserver
> on the repository server system. Then I could
> go to a box (other than OS X) and retry checking
> out a repository and wham ... nice and fast again.
> Now I haven't fine grained testing exactly what
> caused the checkout hang condition, e.g. I have
> not tried rebooting OS X and trying just the
> command line 'svn' command, then rebooting, etc.

I wasn't impressed with any graphical Subversion client for Mac OS X
so I've been just using the command line (installed from
darwinports). Try it with the command line client and see what happens.

> Also, while the hang was going on I inspected
> the repository server via top and it wasn't breathing
> hard, low cpu usage, lots of memory free, etc.

I'll again suggest my favorite issue, that the server may have run
out of entropy. Is your APR compiled to use /dev/random? Can you try
recompiling it to use /dev/urandom?


> So some lock condition had occurred on the fsfs
> svn repository.
> I'm wondering if svnX in the 'repository view'
> mode is grabbing and locking down the repository
> and whether that lock is not auto cleaned when
> the program dies. (and I did double check that
> I'm running fsfs backend for the svn repositories
> and I know that fsfs is not supposed to get
> wedged the same way the other db backend does).

As far as I know, there aren't any such locks that a client could
request. The system's designed to let people work concurrently, so I
don't think it's intentional in this case for one client to be able
to bring down the whole system.

This is different, of course, from the new per-file locks, which are
of course intended to lock you out of specific files while someone
performs a non-mergeable change.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Nov 17 21:27:24 2005

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.