How to develop on a (GHC) branch with darcs

[Lennart Augustsson]

Like everyone else I have no good solution.
When I had a ghc branch I used diff and patch to move my patches forward.
Not exactly what you expect to have to do with a version control system.

On Mon, Dec 6, 2010 at 1:57 AM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> 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
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>