Darcs

[Manuel M T Chakravarty]

Simon Marlow:
>  - conflicts: working with non-trivial branches on darcs is  
> practically
>    impossible.  A fix is in the works, but it's not clear how long it
>    will be before it is available in a released darcs version.

I don't think this is entirely fair.  It's trivial to have branches  
with darcs *if* you are prepared to abandon your history on a merge.   
With many other (at least the non-distributed) vcs, you always lose  
your history on a merge.  So, the conflict bug prevents us from  
getting the added value that we would like to get from darcs, but it  
doesn't necessarily put us into a worse position than with other vcses.

(Don't get me wrong, I do hate the conflict bug and it has bitten me  
quite badly.)
>
>  - speed: many operations are impractical (annotate, darcs changes
>    <file>), and many operations just take "too long" (i.e. long enough
>    that you go and do something else rather than wait for it to  
> finish,
>    which incurs a context-switch cost).

My main gripe with speed is actually pulling (esp darcs-all as it  
involves many repos) and push, which partially is a network issue.
>
>  - user interface issues: e.g. in a conflict there's no way to tell
>    which two patches are conflicting with each other(!)

Yes, that's annoying, but otherwise people seem to agree that darcs ui  
is rarely matched by other vcses.
>

> What should we consider as alternatives?  At least Mercurial and  
> git, I would think.   Any others?  I think we should only consider  
> distributed VCs.

Interesting are these two blog posts:

   http://hans.fugal.net/blog/articles/2007/11/16/mercurial-and-darcs
   http://hans.fugal.net/blog/articles/2007/11/20/darcs-and-mercurial-redux

Personally, I'd say let's stick with darcs a little longer, esp given  
that David seems to have a serious go at the merge problem at the  
moment.

Manuel