In 
http://log.ometer.com/2004-11.html#19
Havoc Pennington discusses (and itemizes) various functionality that he would like to see in a revision control system.  I've tried to answer his point from a darcs point of view - of course, I encourage others to correct and extend.

== Why darcs is so nice ==

I think the nice aspects of darcs are:

 * No complex setup or servers or protocols or nothing.  If you can
   read the repo, you can work with it.  Local file, NFS, ssh, or
   HTTP.  If you can write to it, or just send email, you can submit
   patches. 

 * Branching and merging is performed with very simple
   commands, and just work.  No added complexity in the repository. 

 * Patches flow unobstructed between repositories.  Adding bugfix
   releases from the unstable repository is a breeze.

== Havoc Pennington's items ==

Havoc has been looking at a replacement for CVS, and found many alternatives. His blog entry set his personal baseline for source control tools, he writes:
  "it sounds useful to see which of these systems most nicely supports our current process and social organization."
  "Here are some example tasks:"

     * ''Starting work on a new patch with a defined goal ("I want to
       fix bug #123456")''

Darcs allows this perfectly;  doing a {{{darcs get}}} on your stable branch makes a clean copy which gives you this.  Darcs tries hard to preserve space using hardlinks as well.

     * ''Submitting a patch to the mainline project ("Dear maintainer,
       here is my fix for #123456, please apply")'' 

After fixing the bug you type {{{darcs record}}} writing "fix bug for #123456" in
the description, for the maintainer to see. Now type
{{{darcs send}}} to mail it to the maintainer for integration.  If you are a
maintainer of the parent repo (and have write access) you can use
{{{darcs push}}} to apply it directly.

     * ''Reviewing pending patches for one's own mainline project''

Examine the contents, and do {{{darcs apply}}} if you're happy.  It is of
course easy to create a separate branch if you want to do some testing.

     * ''Accept/reject patches, with comments''

No support -- I think -- for extra comments on the way.  Rejection
must also be handled outside.
In darcs we use a mailinglist for this purpose since the {{{darcs send}}}
delivers the patch via email, this is a natural fit.

     * ''Make a new development release''

Darcs suggests you have a tree on disk for your development version (HEAD in CVS) as well as a bugfixes-only tree.  Patches flow between them with ease.  So this is a no-brainer. After that:
Cd to the development tree, and {{{darcs dist}}}
tgzs up the version-controlled files for you.  

     * ''Make a new bugfixes-only stable release''

Ditto, but {{{cd ../stable}}} first.

     * ''Backport a fix from the development version to the stable
       version''

This comes naturally to darcs,  flowing patches between any branch is easy.
Do {{{cd stable; darcs pull ../unstable}}} and answer yes to the patch(es)
you want.  Or specify the patch with -m if you know the name and want
to save some time.

    * ''Restore a recent (perhaps never-submitted-to-mainline) version
       of a file you're working on, since you just accidentally
       deleted it'' 

If you deleted it but didn't record the deletion, you can undo the
deletion with {{{darcs revert}}} (which will prompt for the various
changes you have done).  If the deletion is recorded, you can
{{{darcs unpull}}} the patch responsible, or {{{darcs unrecord}}} it and
{{{darcs revert}}}. 
Doing a {{{darcs revert myLostFile}}} is even faster.

     * ''See what changed recently that may have broken the build''

Darcs suggests you put unit-testing as part of your {{{darcs record}}} strategy, which makes sure you never get a non-compiling build, at least.  But the request still is possible:
Do {{{darcs changes}}}, using switches for selecting the desired verbosity.

     * ''Get the latest version of the software''

Do {{{darcs pull}}}, or {{{darcs pull -a}}} if you want it all.

     * ''Adapt a patch to work with a different version than the one
       you wrote it for (aka resolve conflicts)''

In many cases the patch will slide in place without conflicts, as
darcs knows how to commute patches.  Conflicts do arise when
incompatible changes have been made, and the normal behavior is to
mark conflicts in the file, and let the user manually decide and
record a new patch resolving the conflict.

== Havoc's feature ideas ==

Further down in his blog, Havoc lists the following:

     * ''The version control system keeps track of how to submit
     patches (mailing list, bugzilla, etc.) and has a "submit patch"
     command. (Prereq: the system has a concept of a patch you're
     working on for submission)''

Check.  Darcs remembers where a repository came from, and by default
passes patches the same way.  You can of course specify something
else.

     * ''The version control system tracks submitted patches for the
       maintainer and supports easy review and acceptance/rejection
       of them.''

Patches submitted with {{{darcs send}}} can be reviewed at the
maintainer's leisure, of course.

     * ''Easy way to have a conversation about any patch (as we do now
       in bugzilla typically)''

Not part of darcs.

     * ''Allow the maintainer to easily hack on the patch, merge their
     changes with it, and then bounce the patch back to the submitter
     for more work - I often want to just fix the nitpicks instead of
     writing them down, then give someone the patch back to fix the
     big stuff.''

I'm not entirely sure what you mean here.  One scenario is that you
create a new branch ({{{mkdir developer; cd developer; darcs get ../unstable}}}),
apply or pull the patch in question there, fix the nitpicks, {{{darcs record}}} them, and tell the developer to pull that patch.  

     * ''Often you want to commit a number of times before you submit a
     patch officially (sometimes people will make a CVS branch for
     this). A nice feature would be to avoid the need to do this
     manually; just have the developer tools automatically "commit"
     every time you save from the editor, or even make the whole undo
     buffer persistent. Much more plausible with monotone than with
     CVS.''

I don't like this, as often changes to different files belong together
logically (but you could of course hook the command {{{darcs rec -am "autosave"}}} from Emacs' save-buffer, or similar).  You can later
rearrange the patches more logically, but only as long as nobody
has pulled them.