Version control systems
Manuel M T Chakravarty
chak at cse.unsw.edu.au
Mon Aug 11 20:46:30 EDT 2008
> 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
> 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
> 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
> 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.
More information about the Glasgow-haskell-users