Re: [darcs-users] How to develop on a (GHC) branch with darcs
Hi Simon, On 12/08/2010 12:45 AM, Simon Peyton-Jones wrote: I have personal experience of git, because I co-author papers with git users. I am not very technologically savvy, but my failure rate with git is close to 100%. Ie I can do the equivalent of 'pull' or 'push' but I fail at everything else with an incomprehensible error message. Maybe I just need practice (or more diligence), but I really don't understand git's underlying model, despite trying, and reading several tutorials. If anyone has a favourite how to understand git doc, do point me at it. If you still are looking for git docs (or christmas gifts, for that matter ;), I've heard good things about Pro Git: http://www.amazon.com/Pro-Git-Scott-Chacon/dp/1430218339/ref=sr_1_1?ie=UTF8qid=1293052240sr=8-1 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: [darcs-users] How to develop on a (GHC) branch with darcs
| thoroughly exhausted. Even when Darcs was in a far | less advanced state than it is in now, the conclusion seemed | to be that the best interests of the Haskell community at | large are served by remaining with Darcs. So it would be a bit | strange if this branching issue, which is a serious issue | currently but will likely become a non-issue in a few months time, | triggers GHC to abandon Darcs. Let's not go overboard here. Iavor was expressing his frustration with using Darcs, and that is useful information for the Darcs devs to have, so they know where to focus their efforts. Already this thread has generated new useful information. For example, Iavor knows about --skip-conflicts, and I know that things might be better in months not years. Neither of us knew those things before. For GHC, we have two strong incentives to stick with Darcs. First, we use it at the moment and there'd be a lot of hoo-ha to change. Second, Darcs is written by people in our community, and GHC is a big customer, so I for one am keen to be supportive. But we don't want to discourage people who'd like to help with GHC either. For example, here is one response to the thread, from Tim Middleton: | For the record, I can say that as a Haskell fan and someone who's using | Haskell at work (for small tools and projects), and as someone who'd like | to contribute to GHC (especially to the cross-compiler effort), having to | work with darcs is a very frustrating. The more everyone can do to understand what the frustration is, and to describe workflows that make it as easy as possible, the better. Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [darcs-users] How to develop on a (GHC) branch with darcs
On 08/12/2010 17:39, Yitzchak Gale wrote: Some of those are already in the works, and all except possibly (5) are known to be within reach. So the answer is yes, this problem is now on the verge of being solved in Darcs. I think that might be a little overoptimistic. The fundamental problem with darcs is that nobody understands the semantics. Until there's a proper semantics that people can understand, I don't think the problems with merging and conflicts can really be fixed. Even if the semantics can be nailed down, there are some difficult UI issues to solve. We're not moving to v2 patches right now because we have enough experience with v1 to know how to avoid the bugs, but I'm less sure we could avoid the bugs in v2. To the darcs folk: do you think this is unfounded paranoia? On the other hand, I suppose GHC HQ can't afford to have a revolt on their hands. So if the majority of people doing the actual work on GHC want to change to git and are willing to put in the effort to make the change, it will probably happen regardless. Opinion on whether we should switch seems to be pretty evenly split at the moment (personally I'm agnostic). Besides that, the main stumbling block is that the GHC tree consists of about 20 repos, with different maintainers, so making it so that a GHC developer only needs to use one VC tool could be tricky. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [darcs-users] How to develop on a (GHC) branch with darcs
Hi Simon, Simon Peyton-Jones simo...@microsoft.com writes: | known problem with darcs with no obvious solution. For me, switching | GHC to git would certainly be a win. I have personal experience of git, because I co-author papers with git users. I am not very technologically savvy, but my failure rate with git is close to 100%. Ie I can do the equivalent of 'pull' or 'push' but I fail at everything else with an incomprehensible error message. Maybe I just need practice (or more diligence), but I really don't understand git's underlying model, despite trying, and reading several tutorials. If anyone has a favourite how to understand git doc, do point me at it. I've felt the same for quite some time. Therefore I used to prefer mercurial, because of its way more consistent user interface. But my view has changed after I've seen this [1] introduction of magit [2] an emacs git user interface. Now, I feel at least capable of working with git in emacs. [1] http://vimeo.com/2871241 [2] http://philjackson.github.com/magit/ Cheers, Jean-Marie ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [darcs-users] How to develop on a (GHC) branch with darcs
On Thu, 9 Dec 2010, Simon Marlow wrote: On 08/12/2010 17:39, Yitzchak Gale wrote: Some of those are already in the works, and all except possibly (5) are known to be within reach. So the answer is yes, this problem is now on the verge of being solved in Darcs. I think that might be a little overoptimistic. The fundamental problem with darcs is that nobody understands the semantics. Until there's a proper semantics that people can understand, I don't think the problems with merging and conflicts can really be fixed. Even if the semantics can be nailed down, there are some difficult UI issues to solve. We're not moving to v2 patches right now because we have enough experience with v1 to know how to avoid the bugs, but I'm less sure we could avoid the bugs in v2. To the darcs folk: do you think this is unfounded paranoia? Sadly, no. On the other hand, I suppose GHC HQ can't afford to have a revolt on their hands. So if the majority of people doing the actual work on GHC want to change to git and are willing to put in the effort to make the change, it will probably happen regardless. Opinion on whether we should switch seems to be pretty evenly split at the moment (personally I'm agnostic). Besides that, the main stumbling block is that the GHC tree consists of about 20 repos, with different maintainers, so making it so that a GHC developer only needs to use one VC tool could be tricky. My feeling is that a bridge should be quite feasible and would offer those contributors who want it the opportunity to do their GHC development in git and only use darcs when submitting their final changes or when working in unbridged repos. I'm not too familiar with the structure of the GHC repo but I suspect that only a few of the subrepos are big or active enough that darcs is really painful. Cheers, Ganesh ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [darcs-users] How to develop on a (GHC) branch with darcs
On Wed, 8 Dec 2010, Stephen J. Turnbull wrote: Ganesh Sittampalam writes: I think there are three things that can help with this problem: 1) a darcs rebase command. This will give you a nice way to manage the workflow already discussed, and you won't have to squish everything through into a mega-patch. You'll still have to periodically abandon one branch for another though (but I think that's also the case with git rebase). I'm not sure what you mean by abandon. I mean the same as in the git world. The rebased patches have new identities, and if my ideas for tracking the relationship don't work out, they will have no relationship to the old patches. [your very clear explanation of that snipped] I also have some hope, though this is more speculative, of offering a clean way of tracking the relationship between the old branch and the new branch so that any stray patches against the old branch can be cleanly rebased to the new branch later on. As explained above, DAG-based VCSes like git can't do this cleanly (that is one way of expressing the reason why rebase is severely deprecated in some circles), and I don't think git will be able to do so in the near future. OTOH, if Darcs gets rebase but can't handle this, I'd have to count that as a net minus. Recombinant patching is really what Darcs is all about IMO. darcs rebase is essentially about giving up on the recombinant patching because that's not working out for whatever reason. It's primarily intended as an alternative to manually reapplying patches to new branches using diff-and-patch, which is something significant numbers of people have ended up having to do. People generally want/need to do this to avoid conflicts, because: (a) darcs conflict handling can blow up, both because of exponential merges (primarily with v1 patches) and because of bugs (b) the UI for dealing with conflicts isn't really that pleasant and in particular once you've resolved a conflict it's a little painful to see the overall effect of the conflict resolution together with the underlying patch In practice, git rebase needs to be kept private to a single user, and is impractical even if private, if the user has propagated the branch to other local repositories. Because git branching is so lightweight, nobody really sees this as a big problem; throwaway branches are used all the time as interim steps in many operations (eg, git stash). Darcs branches, on the other hand, are much more heavyweight (modulo the work you propose on colocated branches, but that's farther away than rebase is). IMHO YMMV. But I strongly recommend you think carefully about this. Analogies to git rebase are a trap here. It's implemented differently and used to solve different problems from the way rebase is proposed for use in Darcs. My understanding is that one of the main uses for git rebase is for cleaning up history prior to submission. In that regard I think there's a substantial overlap with what darcs rebase is intended for. Thanks for the detailed comments. Ganesh ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: [darcs-users] How to develop on a (GHC) branch with darcs
| known problem with darcs with no obvious solution. For me, switching | GHC to git would certainly be a win. I have personal experience of git, because I co-author papers with git users. I am not very technologically savvy, but my failure rate with git is close to 100%. Ie I can do the equivalent of 'pull' or 'push' but I fail at everything else with an incomprehensible error message. Maybe I just need practice (or more diligence), but I really don't understand git's underlying model, despite trying, and reading several tutorials. If anyone has a favourite how to understand git doc, do point me at it. Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: [darcs-users] How to develop on a (GHC) branch with darcs
I like Git for Computer Scientists [1] and Git in pictures [2]. It also sounds like a Git for Darcs users might be in order. Edward [1] http://eagain.net/articles/git-for-computer-scientists/ [2] http://blog.nelhage.com/2010/01/git-in-pictures/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [darcs-users] How to develop on a (GHC) branch with darcs
On Wed, Dec 8, 2010 at 12:31 PM, Edward Z. Yang ezy...@mit.edu wrote: I like Git for Computer Scientists [1] and Git in pictures [2]. It also sounds like a Git for Darcs users might be in order. Once you got the general ideas down I'd recommend http://nvie.com/posts/a-successful-git-branching-model/ as a way to work with branches. Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [darcs-users] How to develop on a (GHC) branch with darcs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/8/10 03:45 , Simon Peyton-Jones wrote: | known problem with darcs with no obvious solution. For me, switching | GHC to git would certainly be a win. I have personal experience of git, because I co-author papers with git users. I am not very technologically savvy, but my failure rate with git is close to 100%. Ie I can do the equivalent of 'pull' or 'push' but I fail at everything else with an incomprehensible error message. Maybe I just need practice (or more diligence), but I really don't understand git's underlying model, despite trying, and reading several tutorials. If anyone has a favourite how to understand git doc, do point me at it. I'm tempted to point out that Linux named it git for a reason. :) Mercurial might be a better choice, especially for people familiar with darcs. - -- 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/sgQACgkQIn7hlCsL25WV7gCdF48m1hMxoQUc/NpW08zfye3P 7+sAnRy8ef3nImblBPGcXQPCzFWbdP2h =/Xf1 -END PGP SIGNATURE- ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [darcs-users] How to develop on a (GHC) branch with darcs
On Dec 8, 2010, at 2:45 AM, Simon Peyton-Jones wrote: If anyone has a favourite how to understand git doc, do point me at it. You may have already tried these, but I've found the [official git tutorial][1] to be pretty decent. The [second part][2] contains some details on how git sees the world. The [everyday git][3] document gives a pretty good idea of how the commands are used in standard workflows. [1]: http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html [2]: http://www.kernel.org/pub/software/scm/git/docs/gittutorial-2.html [3]: http://www.kernel.org/pub/software/scm/git/docs/everyday.html ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [darcs-users] How to develop on a (GHC) branch with darcs
Iavor Diatchki wrote: I use git for a lot of my development... Given the responses though, it sounds like this is a well known problem with darcs with no obvious solution. Why do you say there is no obvious solution? In fact, Ganesh, representing the Darcs team, responded: 1) a darcs rebase command... very much hope to have it in the next darcs release. Simon M has already tried out an experimental version and was quite positive about it... 2) multi-branch repos... perhaps the release after next... 3) Better performance when there are conflicts... [by upgrading GHC to v2 patches] 4) Better UI around managing conflicts... 5) new patch types that reduce the number of conflicts you get at all Some of those are already in the works, and all except possibly (5) are known to be within reach. So the answer is yes, this problem is now on the verge of being solved in Darcs. After focusing mostly on performance for a while and achieving huge gains, the Darcs team has turned a significant portion of its attention to the branching problem for some time now, and the fruits of this labor will begin to become available in the next release. VCS discussions tend to spark religious wars in which zealous proponents of one system conveniently ignore the positive points of another in order to push as hard as possible for the adoption of their darling. Standing somewhat on the outside, it seems to me that the discussion about switching VCS has been more than thoroughly exhausted. Even when Darcs was in a far less advanced state than it is in now, the conclusion seemed to be that the best interests of the Haskell community at large are served by remaining with Darcs. So it would be a bit strange if this branching issue, which is a serious issue currently but will likely become a non-issue in a few months time, triggers GHC to abandon Darcs. On the other hand, I suppose GHC HQ can't afford to have a revolt on their hands. So if the majority of people doing the actual work on GHC want to change to git and are willing to put in the effort to make the change, it will probably happen regardless. Regards, Yitz ___ 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
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: [darcs-users] How to develop on a (GHC) branch with darcs
Hello, Thanks for all your responses (and the --skip-conflicts tip)! I use git for a lot of my development, so I was hoping that I was just experiencing culture shock and simply doing things with the wrong mind-set. Given the responses though, it sounds like this is a well known problem with darcs with no obvious solution. For me, switching GHC to git would certainly be a win. In terms of the future of darcs, while better tools for managing rebasing would certainly be useful, I am not confident that any solution based on mutation (i.e., rewriting history by rebasing/ amend-recoding) would work well in a distributed environment due to the difficulty of sharing these changes---it seems to require some sort of higher order version control where you have to keep track of the changes to the changes :-) In the context of git, I only brought up rebasing because it seemed like the closest concept to what I was doing with darcs. If GHC was to switch to git, I think that we should certainly use git's ordinary merge model to keep track of history. -Iavor PS for VCS folks: I think that an interesting idea of combining darcs and git would be to use git's graph-based history model, but to annotate the edges on the graph with semantic patches ala darcs. This would make it possible to write smarter auto-merge strategies for git. On Tue, Dec 7, 2010 at 7:16 AM, Stephen J. Turnbull step...@xemacs.org wrote: Ganesh Sittampalam writes: I think there are three things that can help with this problem: 1) a darcs rebase command. This will give you a nice way to manage the workflow already discussed, and you won't have to squish everything through into a mega-patch. You'll still have to periodically abandon one branch for another though (but I think that's also the case with git rebase). I'm not sure what you mean by abandon. In a git rebase, you pretty much have to forget the original branch immediately (everywhere in the world!), or there will be great fun for all concerned. You really really do not want to merge an original branch with its rebased descendant in git.[1] Unfortunately, unless the rebased branch gets dibs on the branch's name, it's all too easy to perform such a merge inadvertantly (eg, git pull will do it). So in that sense a git rebase means immediately abandoning the old branch, and all the commit history of the old branch. (The details of the history are copied into the rebased commits, but they do not have the same identity as the originals, so merge conflicts are guaranteed.) I also have some hope, though this is more speculative, of offering a clean way of tracking the relationship between the old branch and the new branch so that any stray patches against the old branch can be cleanly rebased to the new branch later on. As explained above, DAG-based VCSes like git can't do this cleanly (that is one way of expressing the reason why rebase is severely deprecated in some circles), and I don't think git will be able to do so in the near future. OTOH, if Darcs gets rebase but can't handle this, I'd have to count that as a net minus. Recombinant patching is really what Darcs is all about IMO. In practice, git rebase needs to be kept private to a single user, and is impractical even if private, if the user has propagated the branch to other local repositories. Because git branching is so lightweight, nobody really sees this as a big problem; throwaway branches are used all the time as interim steps in many operations (eg, git stash). Darcs branches, on the other hand, are much more heavyweight (modulo the work you propose on colocated branches, but that's farther away than rebase is). IMHO YMMV. But I strongly recommend you think carefully about this. Analogies to git rebase are a trap here. It's implemented differently and used to solve different problems from the way rebase is proposed for use in Darcs. Footnotes: [1] There may be better ways to deal with this than garbaging the original commits, but so far nobody really needs it. ___ 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: [darcs-users] How to develop on a (GHC) branch with darcs
On Mon, 6 Dec 2010, Simon Peyton-Jones wrote: 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.) I think there are three things that can help with this problem: 1) a darcs rebase command. This will give you a nice way to manage the workflow already discussed, and you won't have to squish everything through into a mega-patch. You'll still have to periodically abandon one branch for another though (but I think that's also the case with git rebase). I also have some hope, though this is more speculative, of offering a clean way of tracking the relationship between the old branch and the new branch so that any stray patches against the old branch can be cleanly rebased to the new branch later on. I'm actively working on rebase (with some gaps to refactor the darcs codebase to make working on it easier) and very much hope to have it in the next darcs release. Simon M has already tried out an experimental version and was quite positive about it, though there's significant work yet to do. If anyone else wants to try it, please do: see the thread at http://lists.osuosl.org/pipermail/darcs-users/2010-August/024924.html 2) multi-branch repos. We've pretty much agreed we need these; I think the strongest motivation is being able to keep the same build products around when switching branches. No concrete plans, but perhaps the release after next if we can manage it? 3) Better performance when there are conflicts, so you don't have to rebase as often/ever. For this you need a new patch format. GHC is using v1 patches, but darcs also now has v2 patches, which get into exponential merges much less often - but it's still possible, and we know of bugs in the merging which can hit in complex cases (v1 patches also have a few buggy corner cases). You also have to go through an explicit conversion step to switch to v2. I think we need to have another go at figuring out the problem once and for all (i.e. v3) but we don't know for sure how to do this. Something related, but not exactly addressing the problems you all describe is: 4) Better UI around managing conflicts - one frequently requested thing is to be able to see the names of the patches that caused the conflicts. I'm working on this actively (it's also useful for rebase) and I also hope/expect to have this in the next release. Another thing that'll definitely be in the next release is that conflict marks will include the original text as well, so you can work out what changes each side of the conflict made. In my experience that actually makes a huge difference and it's very annoying we didn't do it earlier. and, once we've got better at the basics, 5) we'd love to add new patch types that reduce the number of conflicts you get at all. Some ideas include hunk move patches that track when you move code from place to place, identation patches, and patches that track character changes to an individual line. Again, no timescale, but having refactored some of the core patch code recently it's now much clearer how we could do this. Finally, I think the future holds more hybrid environments where different people use different VCSes and bridge between them. (At least, I hope so, it's the only hope darcs has of staying relevant in the wider world :-). Petr Rockai's recent darcs-fastconvert tool offers incremental darcs-git conversions, which I think should allow people who are happier with git to use that instead and only convert back to darcs to submit their patches. [It may be that previous tools also offered this, I'm not certain.] Cheers, Ganesh ___ 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
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
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, 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
