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.diatc...@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@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
