GHC version control

[Simon Marlow]

Manuel M T Chakravarty wrote:
> Iavor Diatchki wrote:
>> The mirroring idea seems complex and fragile.  Is there a reason why
>> GHC has to depend on the repository versions of the "external" (i.e.,
>> the ones marked with 'darcs') packages?  It seems to me that it should
>> be possible (and desirable!) to make GHC depend on particular released
>> versions of those packages, and so the source could be obtained in the
>> same way that it is for other Haskell programs (e.g., hackage).  Then,
>> the revision control system used to maintain those packages would not
>> be important from the point of view of GHC.
> 
> That is basically what I meant to say, too.  Only Iavor says it more 
> clearly!

Which is basically suggesting that there should be no (b) packages, only 
(c) (using the classification from Simon's email below).

I think that is probably ok, and desirable as it reduces the number of 
different scenarios that the GHC developer has to think about.  For the (c) 
packages where the GHC git repo contains a snapshot of the package, I can 
imagine also checking out the darcs repo into the GHC tree in order to work 
on the library, and as long as git ignores the _darcs directory everything 
should work fine.  We can push changes to darcs, and also commit the new 
snapshot with git in the same tree.

Of course, we don't plan to do this often, because we'll be using released 
versions of these packages.  But I can imagine it being useful sometimes: 
for example, we'll need to work on Cabal a bit for the new build system, 
but after that I hope we'll be more decoupled from it.

Cheers,
	Simon


> Manuel
> 
>> On Mon, Sep 15, 2008 at 5:58 PM, Manuel M T Chakravarty
>> <chak at cse.unsw.edu.au> wrote:
>>> Simon Peyton-Jones wrote:
>>>>
>>>> In what follows the "Boot Libraries" are the ones required to build 
>>>> GHC.
>>>>
>>>> * So we propose the following:
>>>> - The GHC repo will be in Git
>>>>
>>>> - Each Boot Library will
>>>>      (a) either be mastered in Git, with a read-only Darcs mirror
>>>>      (b) or be mastered in Darcs, with a read-only Git mirror
>>>>    (c) or be mastered in Darcs, with an occasional, manual
>>>>         process to copy a snapshot of the library from Darcs
>>>>         into GHC's Git repo.  (Those Git files should be
>>>>         considered read-only.)
>>>
>>> For (b), will the Git-mirror be automatically updated or patches from 
>>> darcs
>>> be pulled manually?
>>>
>>>> - That means that if we want to modify a Darcs-mastered library
>>>>   we'll have to get the Darcs version, make the patch, test it,
>>>>   push it, and then the Git mirror will be right.  Inconvenient,
>>>>   but we can live with that.  We might even arrange it to be possible
>>>>   for super-developers to use the Darcs repo (rather than the mirror)
>>>>   direct from their tree.  Ordinary developers can continue to be
>>>>   Git-only.
>>>
>>> [..]
>>>>
>>>> * Our specific proposals for the master VCS for each boot library are:
>>>>  hsc2hs                          darcs
>>>>  haddock2                        either: up to David Waern
>>>>  packages/array                  git
>>>>  packages/base                   git
>>>>  packages/base3-compat           git
>>>>  packages/bytestring             darcs
>>>>  packages/Cabal                  darcs
>>>>  packages/containers             darcs
>>>>  packages/directory              darcs
>>>>  packages/editline               darcs
>>>>  packages/filepath               darcs
>>>>  packages/ghc-prim               git
>>>>  packages/haskell98              darcs
>>>>  packages/hpc                    either: up to Andy Gill
>>>>  packages/integer-gmp            git
>>>>  packages/old-locale             darcs
>>>>  packages/old-time               darcs
>>>>  packages/packedstring           darcs
>>>>  packages/pretty                 darcs
>>>>  packages/process                git
>>>>  packages/random                 darcs
>>>>  packages/syb                    either: up to Utrecht
>>>>  packages/template-haskell       git
>>>>  packages/unix                   git
>>>>  packages/Win32                  git
>>>
>>> You do not distinguish between (b) and (c) in that list.  Personally, I
>>> think, every (b) library is a Bad Thing if the Git-mirror update is
>>> *automatic*.  Why?  The setup discourages the library developer from
>>> validating their library changes against the GHC build.
>>>
>>> In other words, every single library that is marked as "darcs" above 
>>> should
>>> be used by ghc at arms length.  That is, ghc should not use the bleeding
>>> edge development version, but  the latest stable version (or something
>>> similar).  When there is a new stable version, the person maintaining 
>>> the
>>> GHC Git mirror of the library ought to validate GHC with the new library
>>> version and only then update the mirror (or the in-place copy in 
>>> GHC's Git
>>> repo).  If it is not possible to use a library's latest stable 
>>> version, the
>>> library is too tightly coupled with GHC to live in a darcs repo.
>>>
>>> Manuel
>>>
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://www.haskell.org/mailman/listinfo/libraries
>>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
> 
> _______________________________________________
> Cvs-ghc mailing list
> Cvs-ghc at haskell.org
> http://www.haskell.org/mailman/listinfo/cvs-ghc