Version control systems

[Manuel M T Chakravarty]

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.

Yes, it's a pain.  However, it is better than two vcs for one project.

>> 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 far as I am concerned, building GHC is turning into a big mess.  We  
discussed ways to improve it again, BUT I'd rather not see it getting  
any messier before it gets better.  Hence, please let's have a  
complete plan that we are convinced will work before making any more  
changes.

> 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.

Yes, we need cabal for packages because we don't want two build  
systems.  However, this does not justify the use of Cabal outside of  
libraries/.  Nobody explained to me why that was necessary.  Why  
change all the rest of the build system.  What is the benefit for the  
ghc project?

To be honest, if you ask me, I'd go back to the old makefile based  
system and remove Cabal from everywhere except building of the library  
packages.

Manuel

PS: Just for some more collateral damage.  Did anybody check whether  
the Mac OS installer support and the -unfortunately, only partially  
working- support to compile for older OS X versions that I added to  
the *makefiles* still works with the Cabal-based system?  I doubt it.   
Took me quite a while to get all this going, and I am not very well  
motivated to spend a lot of time to figure out how it might work with  
Cabal.  IMHO using Cabal for anything but the libraries was a step  
back for no good reason.