Re: Version control systems
On Sat, Aug 9, 2008 at 10:44 PM, Roman Leshchinskiy [EMAIL PROTECTED]wrote: Maybe investing some time in fixing the most obvious darcs problems would be a better solution? We're working on that over at Darcs HQ, but there is no guarantee that we'd come close to fixing the problems within the 4-5 week window that Ian mentioned. Supposing that the main problems GHC has with darcs 2 format get solved in the next month, would that give GHC reason enough to keep using darcs? It seems many of you are eager to use git; perhaps even if darcs was working to satisfaction. People will be working on making darcs work better with the GHC repo as a test case either way. And personally, since I'm not a GHC dev, the decision doesn't affect my life. Having said that, I'm still obviously biased. I'd love for darcs to work well enough that this never came up. Let me throw out one more idea: What if, as a GHC contributor, I could pick equally between git and darcs? My understanding is that, while not optimal, you could use tailor[1] to synchronize a darcs repository with a git one. Offer up both repositories and keep them in sync. Let the masses decide? Jason [1] http://progetti.arstecnica.it/tailor ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Version control systems
On 2008 Aug 10, at 2:12, Jason Dagit wrote: On Sat, Aug 9, 2008 at 10:44 PM, Roman Leshchinskiy [EMAIL PROTECTED] wrote: Maybe investing some time in fixing the most obvious darcs problems would be a better solution? We're working on that over at Darcs HQ, but there is no guarantee that we'd come close to fixing the problems within the 4-5 week window that Ian mentioned. Supposing that the main problems GHC has with darcs 2 format get solved in the next month, would that give GHC reason enough to keep using darcs? It seems many of you are eager to use git; perhaps even if darcs was working to satisfaction. Some people are. I'm more on the side of are we creating a bigger problem than we already have? It's not at all clear to me that switching to git would solve more problems than it would cause --- and if you toss in core libraries possibly needing to stay in darcs, or other projects being abruptly forced to switch to git because the core libs did, it's pretty clearly on the biting off more than we can chew side of things. Let me throw out one more idea: What if, as a GHC contributor, I could pick equally between git and darcs? My understanding is that, while not optimal, you could use tailor[1] to synchronize a darcs repository with a git one. Offer up both repositories and keep them in sync. Let the masses decide? There has been some discussion along those lines, but doing that bidirectionally is logitically difficult. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Version control systems
Malcolm Wallace: I seriously hope the plan is to move all *core* libraries (including GHC's cabal repo) etc over to git, too. * one build system * one vcs This is a chance to make a big step towards accessibility, let's make that step. Ultimately, I don't think git would make ghc any more accessible to new contributors. Darcs is not especially offputting to any beginner who already knows something about VCS in general. What the move to git is about, is making life easier for the *existing* HQ and core contributors. Evaluate it on that basis, and not in terms of unknown (and unknowable) benefits to current non- contributors. Indeed, you should also consider how many contributors you might lose in a move. I am not advocating to move. I am just saying, if ghc moves, every component needs to move on which the HEAD build depends and that is needed in its current development form (eg, *not* alex, happy, cabal). I do hear some significant current contributors having doubts. I can certainly appreciate that having to run 2 VCS in parallel might be confusing and simply make matters worse than at present. It is confusing and it is going to make matters worse as two failure points are worse than one. And two extra tools to learn worse than one. The libraries question is a difficult one. We have made a lot of effort over the last 5 years to build infrastructure and code that is shared and portable across multiple implementations of the language. Is this the time to fork those supposedly common core libraries into ghc versions vs the rest? It would be a pity to fork, but to be honest, I'd rather fork the libs than have to use two vcs for GHC. The only other alternative is to decouple more library releases from ghc releases. Manuel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Version control systems
Jason Dagit: On Sat, Aug 9, 2008 at 10:44 PM, Roman Leshchinskiy [EMAIL PROTECTED] wrote: Maybe investing some time in fixing the most obvious darcs problems would be a better solution? We're working on that over at Darcs HQ, but there is no guarantee that we'd come close to fixing the problems within the 4-5 week window that Ian mentioned. Supposing that the main problems GHC has with darcs 2 format get solved in the next month, would that give GHC reason enough to keep using darcs? It seems many of you are eager to use git; perhaps even if darcs was working to satisfaction. People will be working on making darcs work better with the GHC repo as a test case either way. And personally, since I'm not a GHC dev, the decision doesn't affect my life. Having said that, I'm still obviously biased. I'd love for darcs to work well enough that this never came up. Same here, and fwiw I won't change any of my many other darcs repos any time soon. However, as I have said before, if ghc is to switch, it must be a clean switch, and no messy use of two vcs at the same time for ghc and boot libs. Let me throw out one more idea: What if, as a GHC contributor, I could pick equally between git and darcs? My understanding is that, while not optimal, you could use tailor[1] to synchronize a darcs repository with a git one. Offer up both repositories and keep them in sync. Let the masses decide? I don't think that this technical feasible. I used tailor once to convert a CVS repo to darcs, and while that was better than throwing away the history, it was pretty messy and nothing that you would want to do on a regular basis. Besides, even if the actual conversion would work smoothly (which I strongly doubt), you'd immediately be faced with problems of atomicity and associated race conditions of commits to the two repos. Manuel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Version control systems
On Sat, Aug 09, 2008 at 06:56:23PM -0400, Norman Ramsey wrote: * I violently agree with whomever (Don? Malcolm?) said that the Haskell community will prosper to the degree that we have *one* build system and *one* version-control system. And when the build system or version-control system is standard, we gain eyeballs and developers. I haven't found a standard build system that I am willing to use, but I think git is good enough to be used. * Our long-term goal should be to get the *entire* Haskell development community to agree on a version-control system---one that is not darcs. We should expect this process to take several years, and we should expect it to cost money. Would Microsoft or Galois or York or other large players be willing to donate part of an expert's time to migrate to the new version-control system? It is, of course, up to people with money what they spend it on, but personally I would much prefer to see money spent on making darcs better, for reasons I won't repeat again. If it makes a difference, I would expect a research paper on how conflictors work would be easy to produce as a side-effect, as we would need to get a good description of how it works, and proofs that it does, anyway. Also, I expect we could get a BSDed darcs as a result. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Version control systems
On Sun, Aug 10, 2008 at 02:16:25PM +1000, Manuel M T Chakravarty wrote: Duncan Coutts: I don't especially relish having to learn another vcs tool or raising the bar for contributions to Cabal either (we have lots of people who make small one-off contributions). I don't think it matters what vcs Cabal uses. GHC does already for a while use a separate repo for its version of Cabal, and the GHC Cabal repo needs to be explicitly updated to ensure that changes to Cabal do not randomly break GHC. To be honest, if I had to say anything, I would say that GHC has to uses fixed, stable versions of Cabal (like it does of gmp). So, it really doesn't matter what vcs Cabal uses. Unless we do get to a point where we are literally using tarballs[1] of Cabal, I don't think using a mixture of VCSs for Cabal is a good idea. Having to convert patches from one VCS format to the other sounds like a recipe for a lot of pain and suffering. [1] which I think is a bad idea anyway, as it makes it a lot more hassle to fix Cabal bugs that GHC+bootlibs expose. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Version control systems
On Sat, Aug 09, 2008 at 09:30:52PM +0100, Malcolm Wallace wrote: The libraries question is a difficult one. We have made a lot of effort over the last 5 years to build infrastructure and code that is shared and portable across multiple implementations of the language. Is this the time to fork those supposedly common core libraries into ghc versions vs the rest? I think the non-GHC implementations have been struggling for development time as it is. As you say, we've been trying to increase the amount of shared code, to reduce the burden on them. I think forking the bootlibs would represent a huge step the other way, and, as you said later in your e-mail, may be what finally kills them off. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Version control systems
I had my share of problems with Darcs; working on the GHC API I constantly have to avoid conflicts. My temporary workaround is to not update at all. Maybe switching to Darcs 2 format would help here, but there are other issues. I initially converted GHC to Git to be able to more easily checkout older versions (e.g., to find a build bug using git-bisect) but with external core libraries this just doesn't work. Right now, there is simply no practical way to check out an old, building version of GHC! Even if we'd switch to Darcs 2 this problem could not be solved. We would also still need turn to the Git repo to get change histories for specific files or to run commands such as 'git-blame' (unless you don't mind getting a cup of coffee and some biscuits each time you run those commands). I think we can make things easier for existing library contributors by providing a darcs/git cheat sheet or even a command line wrapper. Previous attempts at creating such a wrapper have been abandoned, possibly because some commands cannot easily be modelled in Git. However, if we accept some limitations this is doable. In particular the tricky commands are: darcs pull -- (save) cherry picking requires patch dependency information darcs push -- same as above (darcs pull -a and darcs push -a both can be modelled easily) darcs replace -- not directly supported in Git, but could be modelled -- with a script. If these missing features don't feel like too big a handicap the change should be fairly easy for existing contributors. (And with some time they can start and learn Git's other features.) For our build woes integrating the libraries and the main GHC repo in one Git repo will be very helpful, since we can now just instruct build bots to try and build revision 12345deadbeef and be happy. / Thomas -- My shadow / Change is coming. / Now is my time. / Listen to my muscle memory. / Contemplate what I've been clinging to. / Forty-six and two ahead of me. PGP.sig Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Version control systems
Hello, I think that we should switch the repositories of the core libraries to git too, not just because GHC is switching, but simply because git is a more reliable RCS. It seems that this does not prevent other implementations from using them---the code in the repositories will be still the same! -Iavor ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Version control systems
On Sat, Aug 09, 2008 at 06:56:23PM -0400, Norman Ramsey wrote: * Our long-term goal should be to get the *entire* Haskell development community to agree on a version-control system---one that is not darcs. We should expect this process to take several years, and we should expect it to cost money. Would Microsoft or Galois or York or other large players be willing to donate part of an expert's time to migrate to the new version-control system? It is, of course, up to people with money what they spend it on, but personally I would much prefer to see money spent on making darcs better, for reasons I won't repeat again. I missed them and wouldn't mind receiving a private note. For the last year I have been hoping to make 'a new darcs-like thing, with a real theory founding it' an important part (one of three) of a grant proposal in distributed computing. So you can see I am in favor of spending money to create a better darcs (which is not quite the same thing as making darcs better; I want to start with a new theory). But I am having second thoughts because I think by the time a proposal reaches a review committee, git may be so firmly entrenched (worse is better) that the work would be considered not worth funding. I realize that I am now firmly off topic, but if people here have opinions, I would be grateful to receive them (perhaps off-list). Norman ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Version control systems
On 2008 Aug 10, at 20:17, Norman Ramsey wrote: For the last year I have been hoping to make 'a new darcs-like thing, with a real theory founding it' an important part (one of three) of a grant proposal in distributed computing. So you can see I am in favor of spending money to create a better darcs (which is not quite the same thing as making darcs better; I want to start with a new theory). Can you elucidate what's wrong with the current one? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Version control systems
Ian Lynagh: On Sun, Aug 10, 2008 at 02:16:25PM +1000, Manuel M T Chakravarty wrote: Duncan Coutts: I don't especially relish having to learn another vcs tool or raising the bar for contributions to Cabal either (we have lots of people who make small one-off contributions). I don't think it matters what vcs Cabal uses. GHC does already for a while use a separate repo for its version of Cabal, and the GHC Cabal repo needs to be explicitly updated to ensure that changes to Cabal do not randomly break GHC. To be honest, if I had to say anything, I would say that GHC has to uses fixed, stable versions of Cabal (like it does of gmp). So, it really doesn't matter what vcs Cabal uses. Unless we do get to a point where we are literally using tarballs[1] of Cabal, I don't think using a mixture of VCSs for Cabal is a good idea. Having to convert patches from one VCS format to the other sounds like a recipe for a lot of pain and suffering. [1] which I think is a bad idea anyway, as it makes it a lot more hassle to fix Cabal bugs that GHC+bootlibs expose. The hassle that having two different repo types for Cabal head and Cabal GHC is part of the price of switching from darcs to git for ghc. Incidentally, that you are concerned about Cabal devel in the GHC tree is a consequence out of using GHC as a guinea pig for Cabal development, which by itself is IMHO a Very Bad Idea. Cabal is supposed to be a tool like Happy or Alex. If Cabal *were* mature enough to be used in GHC's build system in the way it is now, GHC would just use the latest stable release of Cabal and we wouldn't have a problem. So, let's please not use one bad idea (using an immature and constantly changing build tool whose use in GHC's build tree barely anybody understands) to justify another bad idea (using two vcs for one project). Manuel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Version control systems
Thomas Schilling: I had my share of problems with Darcs; working on the GHC API I constantly have to avoid conflicts. My temporary workaround is to not update at all. Maybe switching to Darcs 2 format would help here, but there are other issues. I initially converted GHC to Git to be able to more easily checkout older versions (e.g., to find a build bug using git-bisect) but with external core libraries this just doesn't work. Right now, there is simply no practical way to check out an old, building version of GHC! Correct me if I am wrong, but this sounds as if you support my point that switching the GHC repo to git without doing the same for the core libs (in an integrated way) would not address the problems you experienced with darcs. Manuel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
