Version control systems

Manuel M T Chakravarty chak at cse.unsw.edu.au
Mon Aug 11 20:46:30 EDT 2008


Ian Lynagh:
> Even the current situation with Cabal is a bit of a pain, as it's easy
> to forget to push patches upstream as well as GHC's repo, and that's
> just with 2 repos of the same VCS.

As I said before, IMHO it is a big mistake for ghc to depend on  
development versions of Cabal.  GHC should only depend on stable Cabal  
versions.

> I actually think the original plan, where only the ghc repo (plus  
> one or
> two others) is in git is preferable. You may have to use a different  
> VCS
> for different subprojects, but after that it's downhill all the way.
> You don't have to worry about patches being converted from one VCS to
> another, moved to another repo, converted back and merged back into  
> the
> first repo.

Having two vcs for one project is bad.  One reason to switch to git (I  
am told) is that people had problems with darcs on some platforms  
(windows and Solaris, for example).  How is that going to be any  
better if part of the project is still in darcs?  So, can we please  
make up our mind?  If darcs has problems on some platforms, then we  
should not use darcs at all for ghc.  If darcs does not have problems  
on some platforms, then there is one less reason to switch.

All core library developers need to use git anyway to validate their  
core library patches.  So, let's just move the ghc repo and *all core  
libraries* over to git.  If git is good enough for the ghc repo, it  
should be good enough for the core library repos as well, shouldn't it.

Manuel



More information about the Glasgow-haskell-users mailing list