Re: [tlug] Open-source repository question

[Curt Sampson <cjs@example.com>]

On 2009-07-15 10:17 +1000 (Wed), Jim Breen wrote:

> I'd like to pull together some of the variants and place the whole thing
> on a public repository such as SourceForge.

If your purpose is only to make the repository public, I'll point out
that there's no need to go so far as to use a separate hosting site.
Both git and darcs will let you host a publically readable and clonable
repo from any old HTTP server. In the Darcs case, you simply stick a
repo somewhere under your docroot. (You may need directory listings
enabled in your web server configuration as well; I don't recall.)
In the git case, you do not need listings enabled, but you do need
to remember to chose a slightly different repo format (a "bare" one,
without a working copy).

If you already have a web site, and you're happy with having people
mail you patches that you then integrate as you see fit (i.e., the
centralized merging model so popular with users of these so-called
"distributed" VCSs), git or darcs will work very well for this, and
you'll have the advantages of a) using the same infrastructure for, and
having the same control over, the repo as you do for your current web
site, and b) having the repo address use your web site's domain name
rather than a different one.

If you want others to be able to commit to your master repo
independently, but still host the repo yourself, you're going to have
to go a bit further. I prefer to do this via ssh, and it can be done
safely (i.e., giving the other developers access to commit via ssh,
but no other access, such as shell access to the machine hosting the
repository) with both git and Subversion. Git has a wonderful system for
this called gitosis which requires setting up only a single Unix account
used by all users; I'm a big fan of this. I have a home-grown similar
system for Subversion, but it does require setting up individual Unix
accounts for each user, which is rather more of a pain, I find. Contact
me if you're particularly interested in the latter and I'll get the
scripts and details to you.

As far as which VCS to chose, I've used only four in anger:

    CVS: Don't even bother. Subversion does everything that CVS does
    and more, and does it more simply and reliably.

    Subversion: Good and simple user interface that I think more
    developers than any other know well or can learn quickly. Excellent
    support for decentralized merging to a single branch (see below).
    Poor support for decentralized merging (e.g., no cherry-picking
    tool). Distributed repo support is available via svk, but it's not
    as clean or easy to use as git or darcs.

    Git: Probably the most popular DVCS. Faster than most for many of
    the most common use cases; the main exception is when dealing with
    very large repos with large files (e.g., a multi-gigabyte repo
    containing files of tens of megabytes in size--I hear Perforce far
    outperforms git for this).

    Darcs: Not as popular, and users of older distros may have to do a
    source build if you're using Darcs 2.0 and their packaging system
    has only 1.x. Not terribly fast. Has some UI issues (such as the
    default action for a merge of conflicting file additions being to
    delete the file--ouch!). Has a so-called "theory of patches" which
    some claim gives it a sound foundation that other DVCSs don't have,
    but which actually is probably not such a thing. I can't compare the
    merging tools with Git.

Regarding git versus darcs;

    1. That "Haskell" switched from darcs to git is an inaccurate enough
    statement that I'd probably not take too seriously the opinions on
    this held by someone who expressed it that way. However, it is true
    that a very large open source project written in Haskell (GHC, one
    of the four major Haskell compilers or interpreters under active
    development, and one of the many hundreds of projects hosted under
    the rubric of haskell.org) switched, and for good reasons.

    2. I have personally abandoned darcs and use git myself; I found git
    to be faster, easier to use, and have fewer UI "gotchas." However, I
    have little enough experience with each that this should be taken as
    a very tentative recommendation only.

I alluded above to some "centralized versus decentralized merging"
issues. Using git (and gitosis) with a team of four developers over
the three days of the ICFP programming contest last month, we ran into
a fairly annoying problem with git for which there is apparently no
solution, though there has been some discussion about adding features
to help fix this. 

In Starling's programming style, we fairly frequently have two
developers working in separate checkouts on the same piece of code, at
the same time. The typical case is that two developers pair up and start
adding a feature, and realize that some API used within that area of
code is not quite right. So we agree on an appropriate API change, one
developer start implementing that in a separate, fresh checkout, and the
other carries on with the feature change working more or less to the
new API rather than the old one. When the developer changin the API is
finished, he commits that change, and then the other developer does an
svn update, merges that change directly into his working copy, finishes
the feature, and commits. You'll note that during this process there
never exists a committed version of the code that does not build and
work properly.

The problem here is that git appears to have no way to let you merge
new commits into your working copy. Instead, you have to commit your
changes, resulting in a commit of a broken system with half of the new
feature, pull the other changes, do the merge and finish the feature,
and commit again. I suppose you can then go back and merge those two
separate commits into one commit that is a patch to move from the new
API without the feature to the new API with, I suppose, but that seems
less convenient to me. (On the other hand, it may not be so bad; I'll
have to try it a few times and see.)

> - should I set it up for configure/make/make install? (I don't
> at present) If so, what's involved?

You may want to consider using something simpler than autoconf, if you
don't need certain of autoconf's features. Autoconf is not really so
nice to use.

QAM (http://www.starling-software.com/en/qweb.html) could be very nice,
especially if you want to let people easily run automated tests, but for
a first-time user is probably not a non-trivial amount of work to set up,
and the way it keeps the stuff it builds entirely separate from the usual
/usr/bin, /usr/lib etc. may be something you don't want.

Probably the best option here is to start with a simple "set up and do a
quick test" shell script, which will give you a better idea of what you
really need, and then see what you want to add from there.

On 2009-07-15 19:34 +0900 (Wed), Stephen J. Turnbull wrote:

> Windows users dislike git, so git is not necessarily the best choice
> even if communication among developers is the goal.

The plural of anecdote is not "data," but we had one developer working
with Windows in our ICFP contest group, and he had no problem with git.
He's since worked on other things within git repos as well.

cjs
-- 
Curt Sampson       <cjs@example.com>        +81 90 7737 2974
           Functional programming in all senses of the word:
                   http://www.starling-software.com