On Mar 14, 2007, at 4:53 PM, Aaron Novstrup wrote:
> I also have this problem (using subclipse 1.2.0, svnkit, eclipse
> 3.2.1 build M20060921-0945), but others in my company using the
> same subversion server do not. Any other ideas, or advice on how
> to debug this to generate a useful bug report?
I'll go one step farther, even, than Mark, and suspect that the hang
isn't in Subclipse, isn't in Subversion, isn't on your end at all,
but is actually on the server side. Accordingly, if there's any
loggage to be had, it would be at that end. No one in this thread
has described much about their Subversion server configuration.
As it happens, I'm mostly familiar with the HTTP server
configuration; in that case, you can check the Apache HTTPD logs
(both access and error). If nothing else, you should be able to spot
entries in the access log that correspond to your hung operations
(your name, your files), and with time stamps that appear
surprisingly out of order (httpd notes the time the request
processing began, but only logs when the processing ends, so long
hangs like this end up logged out-of-sequence).
If all you find is out-of-sequence accesses (but nothing in error
log), then Apache thinks everything's OK, an unhelpful outcome (since
all us humans fell there definitely IS something wrong here!). The /
dev/random thing is a definite possibility; depending on the server-
side platform, there may be a /dev/urandom as well (OS X provides
both), and if so rebuilding the server to use that would eliminate
the hang. (You don't get true cryptographic randomness, but
Subversion's not actually doing cryptography anyway, so who cares?)
If you do find error_log loggage, then fix whatever it's complaining
about ;-)
If you don't even find out-of-order access_log records, then you've
at least proved that I'm wrong in suspecting your server ;-) If it's
not the server, it must be the client. If you're using "svn+ssh://"
or "https://" URLs, then it could be the /dev/random problem at
client side. These guys actually *are* doing crypto, though, so
switching to /dev/urandom might just possibly be a security problem
for you ... you'll have to assess that trade-off for yourself. If it
seems reasonable, then try using JavaHL built to /dev/urandom (it's
actually neon, I believe, that has to be recompiled).
-==-
Jack Repenning
jackrepenning@tigris.org
Project Owner
SCPlugin
http://scplugin.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: users-help@subclipse.tigris.org
Received on Thu Mar 15 02:30:40 2007