How to develop on a (GHC) branch with darcs

[Iavor Diatchki]

Hello,

I am doing some work on a GHC branch and I am having a lot of troubles
(and spending a lot of time) trying to keep my branch up to date with HEAD,
so I would be very grateful for any suggestions by fellow developers of how
I might improve the process.  Here is what I have tried so far:

First Attempt
~~~~~~~~~~~~~

My branch, called 'ghc-tn', was an ordinary darcs repo.  I recorded
my changes as needed, and every now and then would pull from the HEAD repo.
If conflicts occurred, I would resolve them and record a patch.

Very quickly I run into what, apparently, is a well-known darcs problem
where trying to pull from HEAD would not terminate in a reasonable
amount of time.


Second Attempt
~~~~~~~~~~~~~~

Avoid "conflict patches" by constantly changing my patches.  This is how
I've been doing this:

Initial state:
ghc:      a repository with an up-to-date version of GHC head
ghc-tn:   my feature repo based on a slightly out-of-date GHC HEAD.

Goal:
Merge ghc-tn with ghc (i.e., integrate developments in GHC HEAD into my branch)

Process:
1. Create a temporary repository for the merge:
  darcs clone --lazy ghc ghc-tn-merge

2. Create a backup of the feature branch (strictly speaking not necessary
   but past experience shows that it is a good idea to have one of those).
  darcs clone --lazy ghc-tn ghc-tn-backup

3. Pull features patches from 'ghc-tn' into 'ghc-tn-merge', one at a time.
  darcs pull ghc-tn
  y
  d

  3.1. If a feature patch causes a conflict, then resolve the conflict
       and create a new patch, obliterating the old one:
       darcs amend-record (creates a new patch, not a conflict patch, I think)

After repeating this for all branch patches, I have an updated branch
in 'ghc-tn-merge' with two caveats:

  1. The new repository does not contain my previous build so I have to
     re-build the entire GHC and libraries from scratch.  This is a problem
     because GHC is a large project and rebuilding everything takes a while,
     even on a pretty fast machine.  I work around this problem like this:

    1.1 Obliterate all branch patches from 'ghc-tn'.  This, essentially,
        rewinds the repository to the last point when I synchronised with HEAD.
        To do this properly I need to know which patches belong to my branch,
        and which ones are from GHC.  (I've been a bit sloppy about this---
         I just use the e-mails of the branch developers to identify these and
         then look at the patches.  A better way would be to have some kind
         of naming convention which marks all branch patches).

    1.2 Pull from 'ghc-tn-merge' into 'ghc-tn'.  By construction we know that
        this will succeed and reintroduce the feature changes, together with
        any new updates to GHC into 'ghc-tn'.  Now 'ghc-tn-merge' and
        'ghc-tn-backup' can be deleted.

  2.  The new repository contains rewritten versions of the branch patches
      so---if I understand correctly---it is not compatible with the old one
      (i.e., I cannot just push from my newly updated branch to the public repo
      for my branch as there will be confusion between the old feature patches
      and the new ones).  I can think of only one solution to this problem,
      and it is not great:

    2.1  Delete the original public repo, and publish the new updated repo,
         preferably with a new name.  In this way, other developers who have
         the old patches can either just clone the new repo, or go through
         steps 1.1--1.2 but will not accidentally get in a confused state
         by mixing up the new feature patches with the old ones.

For background, my solution is essentially a manual implementation of what
is done by git's "rebase" command---except that there "branch patches" and
various "repository states" are automatically managed by the system so there
is no need to follow various naming conventions which tend to be error prone.

Apologies for the longish e-mail but this seems like an important
problem and I am hoping that there's a better way to do things.

-Iavor