[darcs-users] Re: darcs'ing fptools

[Manuel M T Chakravarty]

John Goerzen:
> On Tue, Oct 11, 2005 at 10:58:08AM +0100, Simon Marlow wrote:
> > 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.  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?).
> 
> It is possible to have nested darcs repos.
> 
> Whenever you run a darcs command, darcs starts with the cwd and recurses
> up the directory tree looking for a _darcs directory.  So, it is no
> problem to have one repository inside the directory for another on-disk,
> as long as you are careful what you do in the parent repo.  (The
> _darcs/prefs/boring file helps with this as well.)
> 
> The usual method here may look like this:
> 
> 1) User runs darcs get http://darcs.haskell.org/ghc (or smilar)
> 
> 2) This repo contains a script, say getall.sh that is run from inside
>    this new ghc directory.  It will darcs get whatever else is needed.
> 
>    (There should also be an accompanying pullall.sh that will pull down
>    updates from the remote)
> 
> 3) Whenever changes are made, they are darcs recorded like usual.
> 
> 4) Whenever changes are sent upstream, users must make sure to run
>    darcs send or darcs push from the appropriate directory.
>    
>    (Otherwise, changes may be missed.)

I think we should be careful with such constructions.  They require new
users of darcs to learn more to get it right and will trick experienced
darcs users into getting it wrong at least the first time unless they
read the documenatation carefully.

I'd rather have the ghc and libraries repos side by side (instead of
nested).  Then, getting and pulling will require two invocations (which
may be combined by a shell script as proposed) and changes need to be
pushed from each repo containing a change, but at least this is
completely obvious from the directory layout.

> > 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.
> 
> There is some information at
> http://darcs.net/DarcsWiki/Tailor/CvSync#head-ef1c647c5b2be460867dc49aecfb05a6bc02df1f
> about doing this, so it is possible.
> 
> I haven't specifically tried this with tailor & darcs.
> 
> However, in general, it seems that these sort of arrangements are
> somewhat flaky, require a lot of babysitting, and are prone to error.

Given my experience with converting a not-small project from CVS to
darcs (namely c2hs), I agree that a two-way gateway is probably a lot of
work (if it works at all).  tailor generally seems to do a good job of
converting existing CVS history to darcs, but I had to massage the
resulting darcs repo somewhat after the conversion.  I am not sure that
the massaging would have straight-forwardly translated back to CVS.
Moreover, darcs provides functionality (such as moving files and keeping
directories under version control) that CVS does not.  Once people use
that, things should get tricky.

Finally, CVS itself doesn't properly do atomic commits.  Converting
patches between a CVS and a darcs repo might lead to race conditions and
conflicts that are tedious to fix.  In other words, I believe the short
sharp pain of a transition from one system to the other is better than
the continuing agony that will probably result from using both systems
concurrently.

Cheers,
Manuel