Re: [tlug] Darcs and the Lack of Haskell Programmers

["Stephen J. Turnbull" <stephen@example.com>]

Edward Middleton writes:
 > Curt Sampson wrote:

 > > We generally do what might be called "distributed integration": every
 > > developer, upon making a change, is responsible for making sure that
 > > that change is releasable, he needs to integrate it into whatever
 > > branches are going to have it in a release, do all testing necessary,
 > > and make sure that if we rolled those branches out into production right
 > > now, it's going to work. This is a pretty standard Extreme Programming
 > > practice; probably some other agile folks use it too.
[[ ... ]]
 > > So they came up with the integration pumpkin: a stuffed toy pumpkin that
 > > you would take when you were integrating, that served as a global lock
 > > on this, as it were.
 > >
 > > I'd always wondered why they did this, until I started seriously using
 > > Darcs. It turns out that distributed revision control has an issue with
 > > this sort of thing: it distributes the repository, but centralizes the
 > > integration for any particular release branch. This works fine for
 > > something like Darcs or the Linux kernel, where one or a few people do
 > > all of the integration. But it doesn't work so well on my projects,
 > > where every developer is expected to make the release branch releasable
 > > with his changes, and any random team member might be doing the final
 > > changes to make an actual release version.

First let me say that I have no idea what Curt is talking about here.
I do not see why a dVCS would be worse for these purposes than svn, as
long as releases are to be made from a public branch or branches.

My personal experience is that Darcs sucks in a high-churn
environment, especially if you have files that are stacks (GNU-style
changelogs) or queues (diaries), which guarantee that you'll get lots
of persistent conflicts.  Darcs does manage to get rid of some
spurious conflicts, but introduces others (specifically, you must use
Darcs to generate and apply patches or you will run into spurious
conflicts if you try to merge with a branch that did not use Darcs to
apply that patch).  Darcs is very slow and has a UI that frequently
makes it quite easy to divide a set of changes into "coherent
changesets", both of which makes it tempting to record patches late
and infrequently.  Darcs has a very sucky way of indicating merges
(instead of the usual 3-way merge output of

<<<<<<< mainline version 3.1
Ho Ho Ho Chi Minh / O-Bama's gonna win
=======
Hilary's Billary willary sillyry.
>>>>>>> mine

it does

vvvvvvv
Ho Ho Ho Chi Minh / O-Bama's gonna win
=======
Hilary's Billary willary sillyry.
^^^^^^^

gag retch puke -- and consider what happens if you haven't resolved
the conflicts recently and get nested conflicts -- spew), and in
general doesn't help you much with merges it can't avoid.  Then there
are other problems, see the thread I posted (which has gotten longer
and tempers are starting to flare a bit).

 > Perhaps someone who is using git could clarify this, I was under the 
 > impression that it could be used with the following workflow.
 > 
 > Jack> git-clone ..
 > Jacks local repository <- remote repository

Are those ".." supposed to be an ellipsis?  I'm going to assume so,
that you're just abbreviating the uninteresting arguments.

 > Jack> git-branch ..
 > Jacks working copy <- Jacks local repository

This isn't necessary.  The default behavior of git-clone checks out a
working copy.  Branch doesn't check out, anyway.

 > Jack> git-comit ..
 > Jacks working copy change -> Jacks local repository
 > 
 > Jack> git-push ..
 > Jacks local repository -> remote repository

So far so good.

 > If developers Jack and Jill were working on the same branch and pushed 
 > the changes back to the remote repository then the first set of changes 
 > would get committed and the second would throw and error like subversion.
 > 
 > Jill> git-comit ..
 > jills working copy change -> Jill local repository
 > 
 > Jack> git-commit ..
 > Jack working copy change -> Jack local repository
 > 
 > Jill> git push ..
 > Jills local change-> remote repository
 > 
 > Jack> git push ..
 > Jacks local repository -> remote repository
 > * push fails[1]

Yep.

Curt again:

 > > Now that I think about it, I'd say that the problem has nothing to do
 > > with [any of the reasons Steve gave].
 > 
 > I think it is probably more an issue of motivation.  Was there a 
 > satisfactory alternative when the darcs project was started?

No, and there still isn't from the point of view of Darcs fans.  Darcs
is the only VCS that takes the idea of "changeset", rather than
"revision", as primitive.  GNU Arch sort of does, and of course most
VCSes actually store their revisions as patches.  But none of these
are "taking patches seriously", rather they use patches as a method of
compression.  To "take patches seriously" means to have a theory of
when two patches "mean the same thing".  Only Darcs has this, but
their theory is *majorly* broken.[1]

AFAIK the first of the "modern" dVCSes was GNU Arch (2001-2).
Monotone started a little later (2003).  Darcs started in 2004, and
git and Mercurial were both released in mid-July 2005.

 > Git seems to do most of the important tasks darcs does.  Git is
 > looking like it will replace subversion for large public
 > repositories.

Unfortunately, at the moment git has a pretty sucky UI, and Linus et
amis have a pretty sucky attitude toward that problem.  This doesn't
bother me personally, git is my drug of choice, and maybe somebody
(GitHub?) will pick up the ball and run with it for all the UI whiners
out there.  But both Mercurial and Bazaar have substantially slicker
UIs (lots of Do What I Mean and even Do What I Didn't Know I Wanted).
This makes them popular with a certain largish class of users, but
probably substantially worse for building *Hub webapps.[2]  Darcs
shares the boat with them.

Footnotes: 
[1]  For the mathematically trained, it's based on group theory, with
patches forming a group, which implies that a patch must have an
inverse, and that the inverse inverse patch has to be the patch
itself.  However, consider a patch which adds a unique line.  The
inverse must delete that line.  The inverse is not a valid patch by
itself since the line doesn't exist!  The hand-waving starts
immediately....  It's not that this can't be fixed, but they don't
really try.

[2]  My theory is that git was originally a few low-level C programs
for manipulating a fast object database, with the UI built up from
scripts.  I think this heritage makes it likely that it is much better
factored for the kind of abuse a server environment will dish out than
the user-pandering programs like Darcs, Mercurial, and Bazaar.