How to develop on a (GHC) branch with darcs
lennart at augustsson.net
Tue Dec 7 00:21:49 CET 2010
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:
> 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.
> Merge ghc-tn with ghc (i.e., integrate developments in GHC HEAD into my branch)
> 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
> 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.
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
More information about the Glasgow-haskell-users