[darcs-users] [Haskell-cafe] Why not Darcs?

[Marc Weber]

Excerpts from Jason Dagit's message of Thu Apr 21 22:44:25 +0200 2011:
> Darcs has some additional flaws that people complain about, but which I
> don't think are core to the issue:
>   * Conflict markers are hard to understand
>   * patches as a set instead of linear history (patch soup complaints)
>   * It's written in Haskell
>   * It's not popular enough
>   * People say they just don't get patch theory

Let me add:
- Does darcs track real history ? eg history of deployment?
  Sometimes you're not interested in those X ways in which order patches
  could have been applied. Sometimes you just want to know the version
  at a given point in time.

  Eg when packaging snapshots of git/hg/svn projects you can just
  call it "name-hash". How to name a darcs version?

- darcs does not have in directory branches. So you have not only a
  "patch soup" but also a "directory soup".
  For small projects it doesn't matter. However even for hasktags I got
  a patch - asked some questions and no more replies from its author.
  What to do with it? Apply? I didn't feel it was ready.
  Create a branch? How to publish it? So that time I wished I had used
  git - because publishing an additional branch is as easy as
    git checkout -b new-branch
    git push remote-location new-branch
  In darcs? Maybe you have to create many directories on your hosting..

- git in particular also has the concept of "remotes". This means you
  can fetch remote versions without interfering with your local working
  directory. Then you can review. Then you can choose to merge/ ..
  whatever you want.

- git has a staging area:

 workdir -> staging-area -> commit

 This way you can pick changes to be committed.

  mercurial has a "record" command. However its not incremental.
  If you want to correct something you have to start from scratch (?)

- git has the perfect implementation: its garbage collector based.
  You can work and creates commits in any order. However only those
  belonging to tags/branches will be kept when running gc.
  This also allows git to implement reflogs which keep track of the 
  revisions which were checked out .. So its really hard to loose any
  work you comitted once unless you do rm -fr .

  (mercurial creates backup bundles or such)

 Also changing history before publishing (eg tidying up)
 is fastest using git. Well for mercurial there exist histedit plugins
 and such. But they start taking time if you have 20.000 files..

- git is "stupid" - by design. And that's great.
  Eg you can drop remote branches by 
    #git push :name
  the syntax sucks - but hey, if you us bitbucket you have to login
  using the webinterface to achieve the same.
  Probably this depends on your point of view: Some people want to keep
  "all" history. I usually only want to keep the important history.

  And that happens quite often: You get a patch implementing a feature.
  You talk about it. And after some days you have 5 versions of a patch.
  You agree that one version is best and in most cases you can drop the
  other implementations.

  In mercurial you mark branches as dead. However I don't want to keep
  every single temp branch around forever.
  
I'm pretty sure that git advantages:
- branches in the same directory
- remotes
- reflog (?)
- ..
could be implemented in darcs. But they aren't. That's why github is so
easy to use and darcs is not and why I currently prefer git over
everything else.

Mercurial does not have "remotes" either.

If you have a look at "top-git" it gets the job done. However its a huge
mess - because its shell script only. I contributed the tg push feature.
However it took much more time due to the complicated error handling and
such. Probably mercurial pbranch is much cleaner.

In darcs you can't even think about tracking many upstream sources
unless you also want a directory mess.

But this all doesn't matter for small projects.

I may be biased :) I also used git much more than any VCS so forgive me
if one of those statements is wrong.

On any VCS you have to spend several days until you feel comfortable.

The difference git vs darcs:
darcs tracks what could happen (by applying patches)
git is stupid thus tracks what has happened only.

The advantage of darcs is that you could turn it into a smart machine.
Then you would code using darcs rather than an editor:

darcs add function foo()
darcs rename function XY in module ..
darcs add param to function BAR of module  defaulting to null if var XY is not defined in context
...

Well - you get the point - it could be done - but this kind of
refactoring only works on strong typed languages (such as Haskell)
and you still have to take care that those imaginary automatic commands
don't touch your "Changelog" file.

If you look at HaRe then you see that it doesn't even support common
extensions. So it could be done - but a lot of work has to spend to make
this happen..

Also if you start storing asts instead of "human readable code" .. darcs
could be a killer app to keep track of it.

Yours
Marc Weber