Mailing List Archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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




> 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


Home | Main Index | Thread Index

Home Page Mailing List Linux and Japan TLUG Members Links