Re: How to develop on a (GHC) branch with darcs
On 06/12/2010 01:57, Iavor Diatchki 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. Firstly, in GHC we never have conflicting patches in the main trunk, and we never commit conflict resolutions. This is due to darcs' performance and UI issues with conflicts - life is much easier if we have no conflicts in the trunk. (one or two have slipped in by accident in the past, though). In case you haven't seen this, there are some guidelines for using darcs with GHC in the wiki: http://hackage.haskell.org/trac/ghc/wiki/WorkingConventions/Darcs So, when merging a branch with HEAD, you have to rebase, as you noticed. With darcs as it stands, you can't rebase a series of patches with dependencies, so you have to squash your local patch history into one big patch. For my branches, however, I've been using Ganesh's pre-release rebase support. The UI has a few issues, but I've found that if you follow the workflow carefully, it does the job. http://wiki.darcs.net/Ideas/RebaseStatus Don't forget about --skip-conflicts. I have it on by default for pulls in my ~/.darcs/defaults. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to develop on a (GHC) branch with darcs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/7/10 21:42 , David Peixotto wrote: P.S. Apparently Linus used to use Lennart's method of diff and patch for version control before switching to bitkeeper and then git: http://www.youtube.com/watch?v=4XpnKHJAok8 about 10:30 minutes in. I guess it's a sign of a true hacker :) Right up until it bit him in the butt and he released a trashed kernel source tree as a result. (When is about when most people finally figure out that VCSes aren't pointless busywork.) - -- brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkz/AVgACgkQIn7hlCsL25WorwCggF2OuwKWnVufktcfvA3rUZTw kqcAnj5K9UxzhE8/Fx8npAqNOvG39r1d =W2g7 -END PGP SIGNATURE- ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: How to develop on a (GHC) branch with darcs
I too wish there was a good solution here. I've taken to making dated repos, thus http://darcs.haskell.org/ghc-new-co-17Nov10 When it becomes unusable, I make a brand new repo, with a new date starting from HEAD, pull all the old patches, unrecord them all, rerecord a mega-patch, and commit. This is darcs's primary shortcoming. It is well known, and the darcs folk are working on it. But I don't think they expect to have a solution anytime soon. (Please correct me if I'm wrong.) Is the pain of this more than the pain of switching to git? Until now we have not had many active collaborators with their own trees. Now we have at least three: Iavor (numeric types), Brent (new coercions), Pedro (new generics). So it's becoming a much bigger issue. One thing: | Pull features patches from 'ghc-tn' into 'ghc-tn-merge', one at a time. |darcs pull ghc-tn |y |d Darcs can help with that. Use 'darcs pull --skip-conflicts' to pull all non-conflicting patches. Then you can pull a single conflicting patch. That speeds things up quite a bit. Simon | -Original Message- | From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users- | boun...@haskell.org] On Behalf Of Iavor Diatchki | Sent: 06 December 2010 01:57 | To: GHC Users Mailing List; darcs-us...@darcs.net | Subject: How to develop on a (GHC) branch with darcs | | 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, |
Re: How to develop on a (GHC) branch with darcs
How could a darcs guy educate himself about this problem, by following your workflow and trying out some things ? Is there an accessible developer's repo I could pull from to produce conflicts at a similar rate to you ? My usual repos are not so conflictful. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to develop on a (GHC) branch with darcs
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
