1. Summarise the issue (what were doing, what went wrong?)

darcs push shouts at me that it has something important I should be
notified of:

HINT: I could not reach the following repository:
       
/net/csr/srv/csr/repositories/controls/darcs/epics/support/seq/branch-2-1
Finished applying...
      If you're not using it, you should probably delete
      the corresponding entry from _darcs/prefs/sources.

2. What behaviour were you expecting instead?

Silence.

The hint is completely useless and very annoying. 

First of all, *I* did not place the line there, darcs did.

I can delete the whole file or the offending line and it doesn't make
any difference in performance or otherwise for me.

The only reason to delete the line is to get rid of the stupid message.
However, that is also useless, because darcs reliably re-adds it the
next time I use the repo from another machine.

It's not my fault that the same directory has different canonical names
on different machines when using NFS. Normally you don't care because
this is papered over with symbolic links, but unfortunately darcs
insists on resolving them to their canonical name before it stores them.

Is such an extra (sometimes not usable) directory really such a big problem?

3. What darcs version are you using? (Try: darcs --exact-version)

The latest from screened. I think this was introduced after 2.8.4.

Could someone please explain to me what the _darcs/prefs/sources file is
good for. As I said, I can delete it and everything just works as usual
for me, so what difference does its existence and content make?

Depending on the answer, the proper solution would be to either
dismantle the file and all code referring to it or else to either
silently delete unreachable entries (just as we silently add them)
ignore them.

s/ignore them/or ignore them/

It also complains if I make ~/.darcs/cache inaccessible, even though I
have deleted the file _darcs/prefs/sources. The reason I had to make
~/.darcs/cache inaccessible is that otherwise darcs fills up my home
directory, and sooner or later I get errors because my quota is
exceeded. (This is on a shared development machine.)

About ~/.darcs/cache , darcs has this path hardcoded but only as
read-only. This is to take advantage of old cache files. But it never
writes into that directory.

Ah, good to know! I understand now why I had another instance of quota
overflow on our new(-ish) development machine: I started using that
machine with the HEAD of darcs, so my home never filled up with patches.
But recently I reverted back to using darcs-2.8.5 there due to the
'couldnt fetch xxx from sources' problem and I forgot that my
~/.darcs/cache was not disabled.

The discussion continues at
http://lists.osuosl.org/pipermail/darcs-devel/2015-March/016660.html

Ben, do you plan to fix it before the 2.10 release?

I believe this bug was already there in 2.8 so we may just go ahead and
release 2.10 as it is.

I would love to fix this in 2.10 but I am having trouble to find the
time and the concentration to do this right. I guess we will have to
live with the slightly annoying warning messages for the time being.
Perhaps if and when we release a 2.10.1 it will be ready.

To my surprise I have trouble to reproduce the problem (using the same
repo on the NFS server and on the client). When I remove
_darcs/prefs/sources I can't get it to re-create it when I do a pull.
When I create it empty, darcs no longer adds anything to it.

Strange. I could swear I have seen this happening with pre-2.10.0
screened: deleted the line as the HINT suggested and it got re-added by
darcs when I used the repo from the other machine.

http://darcs.net/Internals/CacheSystem might justify some of the sources 
behaviour

Reading through caches doc that a tiny bit (and trying to refresh my memory), 
it looks like the sources mechanism is needed for lazy repositories.

To answer one specific question, `_darcs/prefs/sources` is needed 
for lazy repositories that need to know where to go to get any 
missing patches.

Perhaps if a repository isn't lazy (i.e. has all its patches 
locally) we should just delete it? I'm not sure if it's used for 
anything else.

resolved by

patch a8a44e147336e0e818e5d1d3d629990219dda2af
Author: Ben Franksen <ben.franksen@online.de>
Date:   Mon Nov 19 19:19:13 CET 2018
  * re-formulate the set-default hint