Version control systems

[Simon Marlow]

Manuel M T Chakravarty wrote:

> I think all *core* libraries must switch.  Seriously, requiring GHC 
> developer to use a mix of two vcs during development is a Very Bad 
> Idea.  Don was excited about getting more people to look at the source 
> when it is in git (see the comments he posted from reddit).  By 
> requiring two vcs you will get *less* people to look at the source.
> 
> This is not only to get the sources to hack them, but you effectively 
> require developers to learn the commands for two vcs (when they are 
> already reluctant to learn one).  For example, often enough somebody who 
> changes something in GHC will modify the base package, too.  Then, to 
> commit the overall work, you need to commit using both vcs.  If you need 
> to branch for your work, you need to create branches in two vcs (no idea 
> whether the semantics of a branch in git and darcs is anywhere 
> similar).  When you merge your branch, you need to merge in both vcs.  
> You can't seriously propose such a set up!

I completely agree this is a problem.  The main obstacle with just 
switching the core libraries is that they are shared by other 
implementations and other maintainers.  So I see no alternative but to 
create forks of those repositories for use by GHC, unless/until the other 
projects/maintainers want to migrate to git.  Some of the repositories are 
not shared - for example ghc-prim, integer-gmp, template-haskell, and these 
don't need to be forked.

One way we could create the forks would be to create a git repo for each 
package with two branches: the master branch that GHC builds, and a 
separate branch that tracks the main darcs repository, and is synced 
automatically whenever patches are pushed to the main darcs repo.  We'd 
have to explicitly merge the tracking branch into the master branch from 
time to time.  When we want to make changes locally, we can just commit 
them to the GHC branch and push the changes upstream in a batch later (and 
then we'd end up having to merge them back in to the GHC branch... but 
hopefully git's merge is clever enough to avoid manual intervention here). 
  This is complicated and ugly of course; better suggestions welcome.

> I *strongly* object to moving to git before this isn't sorted out.  As 
> Roman said before, GHC is heading into a dangerous direction.  It gets 
> progressively harder to contribute to the project at the moment.  First, 
> changing the build system to Cabal.  Now, proposing to use two vcs.  
> Somebody who is new to the project not only has to learn the internals 
> of GHC, but they also have to learn two new vcs, and if they need to 
> change the build system, they need to learn a new build tool.  Raising 
> the bar for developers to contribute to a project has been proven to be 
> a very bad idea many times.  Let's not take GHC down that path.

I'm not completely convinced we need to have this all worked out before GHC 
switches, although it would be nice of course.  We currently have 
infastructure in place for the build to work with a mixture of darcs and 
git repositories, and existing developers already have to learn git anyway. 
  They just need to remember to use darcs for libraries and git for the 
main GHC repo, and this is only a temporary situation.


As for Cabal - we had a thread on cvs-ghc last week, and as I said there 
we'd love to hear suggestions for how to improve things, including wild and 
crazy ideas for throwing it all away and starting again.  However, as I 
explained, there are good reasons for the way things are done now, the main 
one being that the build system for packages is not written twice.

Cheers,
	Simon