You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Heitzso <he...@bellsouth.net> on 2005/11/17 18:05:16 UTC
svn checkout hanging
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.
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.
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.
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.
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).
Heitzso
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn checkout hanging
Posted by Heitzso <he...@bellsouth.net>.
Ryan Schmidt wrote:
> 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?
>
> http://svn.haxx.se/users/archive-2005-02/0828.shtml
>
>
>> 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.
>
My svnserver was running on gentoo linux. I set the USE flag
urandom in the make configuration file and tr-emerge'ed apr and
subversion, then restarted the svnserver.
On a separate linux box I checked out a svn repository
Went to OSX and checked out svn repository okay with svn command
On OSX w/ svnX attempted to checkout a repository and locked
everything completely up (all clients stopped working).
Shutdown the OSX box and everything still locked up.
Restarted the svnserve process and everything still locked up.
So did the ln -s /dev/urandom /dev/random (after moving random
out of the way) and restarted svnserve. This time the above
pattern was better, but svnX still paused half a minute or longer
before cranking up the checkout, then completely crashed before
completing it. (A popup came up w/ offer to email bug report
to Apple and I did so).
Other clients were unaffected, i.e. svn checkout svn://blat/blat
worked quickly from other linux box.
Gentoo USE flag doc doesn't mention subversion using the urandom
USE flag. Does subversion use random/urandom strictly out of APR
or does it use it by itself as well? Does a svn client also use
random/urandom?
Heitzso
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn checkout hanging
Posted by Heitzso <he...@bellsouth.net>.
Ryan Schmidt wrote:
> 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?
>
> http://svn.haxx.se/users/archive-2005-02/0828.shtml
>
>
>> 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.
>
My svnserver was running on gentoo linux. I set the USE flag
urandom in the make configuration file and tr-emerge'ed apr and
subversion, then restarted the svnserver.
On a separate linux box I checked out a svn repository
Went to OSX and checked out svn repository okay with svn command
On OSX w/ svnX attempted to checkout a repository and locked
everything completely up (all clients stopped working).
Shutdown the OSX box and everything still locked up.
Restarted the svnserve process and everything still locked up.
So did the ln -s /dev/urandom /dev/random (after moving random
out of the way) and restarted svnserve. This time the above
pattern was better, but svnX still paused half a minute or longer
before cranking up the checkout, then completely crashed before
completing it. (A popup came up w/ offer to email bug report
to Apple and I did so).
Other clients were unaffected, i.e. svn checkout svn://blat/blat
worked quickly from other linux box.
Gentoo USE flag doc doesn't mention subversion using the urandom
USE flag. Does subversion use random/urandom strictly out of APR
or does it use it by itself as well? Does a svn client also use
random/urandom?
Heitzso
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn checkout hanging
Posted by Ryan Schmidt <su...@ryandesign.com>.
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?
http://svn.haxx.se/users/archive-2005-02/0828.shtml
> 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