Zandr the Operations/SysAdmin says that darcs ignoring symlinks "Makes it
challenging to use darcs for system administration tasks.", or words to that effect.

I think that there are at least two reasons why darcs has not yet added a
feature of managing symlinks.  One is that it raises questions about portability
to Windows and another is that it raises questions about security (if symlinks
point to a target outside of the repository, or to a file in the repository that
is not under version control?).

However, the other modern revision control tools seem to have evolved solutions
to these problems which are satisfying to most users, so perhaps we can learn
from them.  This seems like one of those wishlist items that is going to keep
coming up.

Here are a few hits from googling for "darcs-devel symlinks" and "darcs-users
symlinks":

http://lists.osuosl.org/pipermail/darcs-devel/2006-April/004309.html
http://lists.osuosl.org/pipermail/darcs-devel/2005-April/001842.html
http://lists.osuosl.org/pipermail/darcs-users/2007-December/011461.html
http://lists.osuosl.org/pipermail/darcs-users/2003-October/000454.html
http://www.mail-archive.com/darcs-users@darcs.net/msg02700.html
http://www.mail-archive.com/darcs-users@darcs.net/msg04025.html

Just adding a research note on how deals with symlinks:

http://stackoverflow.com/questions/954560/what-does-git-do-to-files-that-are-a-symbolic-link

Note in particular: "BTW. If you are on filesystem like FAT that does not
support symbolic links, and your repository uses them, you can set core.symlinks
configuration variable to false, and symlinks would be checked out as small
plain text files that contain the link text"

The current FAQ suggests to simulate this by version controlling an
update-symlinks.sh script.

# example update-symlinks.sh
ln -s foo/quux bar
ln -s foo/wibble wibble2

# example _darcs/prefs/defaults
ALL posthook sh update-symlinks.sh

But posthooks do not propagate.  It might be useful to have some sort of
posthook-style pref that does propagate, which would also be good for
"version controlling" file permissions.

I'd like to vote for this one.  I've tried to use symlinks before and hit 
this problem.  A project I started on recently has ended up with a load of 
duplicate files because darcs added them twice.

I vote for this too. Modern filesystems have symlinks. It's annoying fact 
to not allow symlinks in darcs. Just threat as binary file, isn't?

I think note about window$ portability is completely irrelevant - due
inadequate filesystem there are plenty of features unsupported in there,
even such a basic thing as creating directories with some names. It
doesn't imply that darcs should not be able to handle those directories.

I think simlynks should be treated exactly the same way as adding
directory 'aux' is treated now: warn user and let him decide by
overriding warning with --reserved-ok

And of course there should be option to override this 'default warning'
globally in some configuration file.

Also, I think it should be tagged bug instead of wishlist - every modern
version control system is capable of handling symlinks.