[darcs-users] Re: darcs'ing fptools

[Malcolm Wallace]

I'm in favour, in a general sense, of moving fptools from CVS to darcs.

"Simon Marlow" <simonmar at microsoft.com> writes:

>    ghc, libraries, hslibs, docs, glafp-utils, nofib, testsuite
> 
> That leaves GHC, namely the subdirectories ghc, libraries, hslibs, docs,
> glafp-utils, nofib, testsuite.  I suggest we create a single darcs
> repository with these subdirectories.  Maybe nofib and testsuite should
> be separate repositories for performance/space reasons, but it would be
> simpler if they were all part of the same repo.

Am I right in thinking that 'hslibs' is going to be dead soon anyway?
Everything in it has been deprecated for some time, so I suggest just
leaving it in CVS, and not migrating it to darcs.

It would be quite nice to have nofib and the testsuite independent of
ghc, so they could be seen as more of a platform-neutral conformance
suite and anti-benchmark, but I'm not really too bothered at this stage.

> What I'm not clear about is how to handle the libraries subtree.  This
> is used by nhc98 and Hugs too, and presumably it would be inconvenient
> for them if they had to 'darcs get' an entire GHC tree just to get the
> libraries.

Yes, definitely.  Besides, there are other Haskell implementations on
the horizon too: UHC, EHC, jhc, yhc, Programmatica, ...  I'm assuming
all of them would like to use the central 'libraries' tree if there
is one.

> Ideas?  Perhaps we should have a separate libraries
> repository from which we can push/pull patches to/from the GHC repo?
> Perhaps we should convert libraries into a darcs repo of its own, and
> then pull it into the GHC repo (how do you create the repos such that
> this is possible - do they have to have a common root of some kind?).

One of those options, or maybe something different again.  I'm not
sure enough of the details of how darcs works to recommend a best
strategy - hopefully someone on the darcs-users list will know.

I do know that in CVS, grafting one repository inside another one
is pretty easy.  However, that is partially because CVS has separate
information inside every subdirectory of the tree.  With darcs, all
the info is gathered centrally at the toplevel, so I don't see how
it would work in the same way.

However, something else to consider.  Should we take the entire
libraries tree across as one single unit anyway?  There are lots of
individual packages in there, and perhaps each could be a separate
darcs repository?  Of course, compilers will want to ship with a
default set of packages, and it would be nice if it were the same
default set for most implementations.

But there is also the issue of a potential social conflict in terms
of any perceived difference in status between the "officially blessed"
libraries, and other decent library packages that, for whatever reason,
are not in that repository.  If moving to darcs is about increasing
participation for developers, then removing any barrier to adding new
library packages into the "official" set is something we are going
to need to address too.  I don't know if that raises any technical
questions about repositories, but I can imagine it might.

> Also, we'll need a two-way CVS gateway between the old fptools and the
> GHC darcs repo (and the libraries repo), at least for the time being.

Agreed.

Regards,
    Malcolm