Manuel M T Chakravarty
chak at cse.unsw.edu.au
Sun Nov 25 20:46:47 EST 2007
> - conflicts: working with non-trivial branches on darcs is
> 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
> - 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
> 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:
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
More information about the Cvs-ghc