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.