Version control systems
Manuel M T Chakravarty
chak at cse.unsw.edu.au
Sun Aug 10 23:35:04 EDT 2008
> On Sun, Aug 10, 2008 at 02:16:25PM +1000, Manuel M T Chakravarty
>> Duncan Coutts:
>>> I don't especially relish having to learn another vcs tool or
>>> the bar for contributions to Cabal either (we have lots of people
>>> make small one-off contributions).
>> I don't think it matters what vcs Cabal uses. GHC does already for a
>> while use a separate repo for its version of Cabal, and the GHC Cabal
>> repo needs to be explicitly updated to ensure that changes to Cabal
>> not randomly break GHC. To be honest, if I had to say anything, I
>> would say that GHC has to uses fixed, stable versions of Cabal (like
>> it does of gmp). So, it really doesn't matter what vcs Cabal uses.
> Unless we do get to a point where we are literally using tarballs
> Cabal, I don't think using a mixture of VCSs for Cabal is a good idea.
> Having to convert patches from one VCS format to the other sounds
> like a
> recipe for a lot of pain and suffering.
>  which I think is a bad idea anyway, as it makes it a lot more
> to fix Cabal bugs that GHC+bootlibs expose.
The hassle that having two different repo types for Cabal head and
Cabal GHC is part of the price of switching from darcs to git for
ghc. Incidentally, that you are concerned about Cabal devel in the
GHC tree is a consequence out of using GHC as a guinea pig for Cabal
development, which by itself is IMHO a Very Bad Idea. Cabal is
supposed to be a tool like Happy or Alex. If Cabal *were* mature
enough to be used in GHC's build system in the way it is now, GHC
would just use the latest stable release of Cabal and we wouldn't have
So, let's please not use one bad idea (using an immature and
constantly changing build tool whose use in GHC's build tree barely
anybody understands) to justify another bad idea (using two vcs for
More information about the Glasgow-haskell-users