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

[Edward Middleton <emiddleton@example.com>]

> Stephen J. Turnbull wrote:
> > It seems from the comments of various people that there just aren't
> > that many Haskell programmers around, not even at the GHC project. I'm
> > not sure whose argument that favors, mine (on the argument that Google
> > should wait around until there are Haskell programmers who can be paid
> > to work on the appropriate things) or Curt's (on the argument that it
> > takes so long to raise up Haskell programmers that anybody who wants
> > to have one in five years should
> >     
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.
>
> Somewhere in all of the original XP books and such that I read,
> someone, probably Kent Beck, described the "integration pumpkin." Now
> on one project I'd read about, they simply had a single integration
> workstation; when you wanted to integrate your new code with a release
> branch, you went over there and did the work. On this particular
> project, though, you could integrate on any workstation, but they ran
> into issues when two pairs of programmers (it was a pair-programmed
> project) were integrating at the same time; they'd stomp on each other.
>
> 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.

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

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

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

Jack> git-push ..
Jacks local repository -> remote repository

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]

1. 
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#forcing-push

> Now that I think about it, I'd say that the problem has nothing to do
> with the relatively small number of Haskell programmers around. It's to
> do with the relatively small number of Haskell programmers available
> that have the ability to work on this sort of problem, and there are
> probably have as many of those as there are in, say, the Linux kernel
> development community. And of course, the also have other difficult
> things to do, such as build a world-class compiler that's right up there
> with gcc, with maybe one-tenth the manpower.
>   

I think it is probably more an issue of motivation.  Was there a 
satisfactory alternative when the darcs project was started?  Git seems 
to do most of the important tasks darcs does.  Git is looking like it 
will replace subversion for large public repositories.  Unless your itch 
is specifically building a better source control application there isn't 
much motivation to work  on it.

Edward