This was originally reported in issue1153, but it is obscured by a handful of
other issues.  This bug report is to draw attention to this specific issue:

If you have a server in your _darcs/prefs/sources which does not respond to ssh
connections, darcs will block for something on the order of 60 seconds.  Here's
how to reproduce this problem:

1.  Do a "darcs pull -a $REMOTE_REPO" which pulls a few patches and see how long
it takes.
2.  Do "darcs oblit --all --last=$X" to remove a few patches so that we can
benchmark how long it takes to repull them.
3.  rm _darcs/prefs/repos
4.  rm _darcs/prefs/sources
5.  /bin/rm -rf ~/.darcs/cache
6.  echo "nobody@192.168.3.2:nodir" > _darcs/prefs/repos
7.  Do the same "darcs pull -a $REMOTE_REPO" that you did earlier.  The bug is
that it takes many minutes -- something 60 seconds for every patch that it pulls.

Hmmmm.  Now I can't reproduce this bug.  :-(

I'm sure that I had this bug reliably before, and I'm sure that I saw it last
week when I was travelling at a security conference.  In both cases, the
solution is to clear out _darcs/prefs/repos and _darcs/prefs/source so that
servers which are currently unreachable are not tried.

There are detailed logs showing this bug happening over on issue1153.  See for
example "out2.txt" in which darcs pauses for long periods of time trying to
connect to the non-existent 192.168.1.147 address.

I wonder why I can't reproduce it?  Argh.

On Thu, Nov 06, 2008 at 08:42:54AM +0000, Zooko wrote:
> If you have a server in your _darcs/prefs/sources which does not respond to ssh
> connections, darcs will block for something on the order of 60 seconds.  Here's
> how to reproduce this problem:
> 
> [...]
> 6.  echo "nobody@192.168.3.2:nodir" > _darcs/prefs/repos
> 7.  Do the same "darcs pull -a $REMOTE_REPO" that you did earlier.  The bug is
> that it takes many minutes -- something 60 seconds for every patch that it pulls.
> 
> Hmmmm.  Now I can't reproduce this bug.  :-(

Could the problem be that your DNS is/was busted, and trying to
resolve foo.org in the original repos/source file was timing out?
That would explain why you can't reproduce it with an IP.

As I mentioned on issue1153, here is the relevant plan from Darcs hacking sprint
#2 (thanks to Petr):

 * check for availability of repo root (that we're fetching from), and if not
available
 * remote: ignore the entry for this darcs (we want to keep the entry in case
it's just transient error)

    "WARNING: can't use <foo> please remove it from _darcs/prefs/sources"

 * long term? on timeout: disable all sources from a given host for this darcs
(URL, Ssh [transient])

I think this has been resolved with Adolfo's Google Summer of Code work
in issue1599