Version control systems

Manuel M T Chakravarty chak at cse.unsw.edu.au
Sun Aug 10 23:35:04 EDT 2008


Ian Lynagh:
> On Sun, Aug 10, 2008 at 02:16:25PM +1000, Manuel M T Chakravarty  
> wrote:
>> Duncan Coutts:
>>>
>>> I don't especially relish having to learn another vcs tool or  
>>> raising
>>> the bar for contributions to Cabal either (we have lots of people  
>>> who
>>> 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  
>> do
>> 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[1]  
> of
> 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.
>
> [1] which I think is a bad idea anyway, as it makes it a lot more  
> hassle
> 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  
a problem.

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  
one project).

Manuel



More information about the Glasgow-haskell-users mailing list