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
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
