This is actually two bugs in one.

First, we should not create a sources file with a relative path.

Second, even if this were an absolute path, it wouldn't make sense 
to add it, since the current repo is /always/ treated as a source, 
regardless of what _darcs/prefs/sources contains (or whether one 
exists in the first place).

This currently causes a lot of unnecessary file operations when 
cloning. The reason is that this extraneous entry is also part of 
the cache we use when we fetch files during clone. Since "." is a 
valid local path, it will take precedence over remote URLs, so for 
each file we first try to read it in ".", which fails, causing an 
exception which we catch with 'catchall' and only then do we access 
the remote repo. This can be easily seen by looking at the --debug 
output of darcs clone.

It should perhaps be noted that converting the relative path to an 
absolute one, removes the extraneous entry. This is pretty counter-
intuitive and it took me quite a while to see why that is the case. 
The reason is the non-standard instance Eq CacheLoc which ignores 
the 'cacheWritrable' field. Since the Writable entry for the current 
repo comes first, the nub in mkCache eliminates any further 
NotWritable entries for the same repo. This is quite brittle and I 
think a fix for this issue should also make this more robust by
avoiding to add the duplicate entry in the first place.