Re: [Haskell-cafe] Why not Darcs?
David Terei wrote: Good chance you've already read this but if not here is a good post by Linus about his take on the problems with darcs: http://markmail.org/message/vk3gf7ap5auxcxnb I always have to smile at the complaint that something is academic. :D You know, like purely functional programming, that's soo academic. It's centered around some academic ideas, like mathematical functions, higher-rank types, monads and zygohistomorphic prepromorphisms, that have absolutely no relevance in real life, and that just don't work in practice. You do *not* want to write whole programs that way. At some point, you need something that works at another level than pure functions. What the *hell* do you do? I think a better invective would be amazing. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
On Sat, 23 Apr 2011, Heinrich Apfelmus wrote: David Terei wrote: Good chance you've already read this but if not here is a good post by Linus about his take on the problems with darcs: http://markmail.org/message/vk3gf7ap5auxcxnb I always have to smile at the complaint that something is academic. :D You know, like purely functional programming, that's soo academic. It's centered around some academic ideas, like mathematical functions, higher-rank types, monads and zygohistomorphic prepromorphisms, that have absolutely no relevance in real life, and that just don't work in practice. You do *not* want to write whole programs that way. At some point, you need something that works at another level than pure functions. What the *hell* do you do? I also found the introduction about 'darcs' being too academic quite silly. However at the end of his invited rant Linus proposes a requirement (or may we call it 'axiom'?), that would be nice to be have: An identifier (a 'version') that can be uniquely mapped to a set of files and their contents. In Darcs this is the darcs history and it is usually the largest part of submitted darcs patches. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
On Sat, 2011-04-23 at 12:31 +0200, Heinrich Apfelmus wrote: David Terei wrote: Good chance you've already read this but if not here is a good post by Linus about his take on the problems with darcs: http://markmail.org/message/vk3gf7ap5auxcxnb I always have to smile at the complaint that something is academic. :D You know, like purely functional programming, that's soo academic. It's centered around some academic ideas, like mathematical functions, higher-rank types, monads and zygohistomorphic prepromorphisms, that have absolutely no relevance in real life, and that just don't work in practice. You do *not* want to write whole programs that way. At some point, you need something that works at another level than pure functions. What the *hell* do you do? I think a better invective would be amazing. Best regards, Heinrich Apfelmus To be fair he realize[s] that's a pretty weak flame, and I'm sorry. He gives reason why he thinks it have no meaning in real live like: Fundmantal example: somebody has a problem/bug. Tell me how to tell a developer what his exact version is - without creating new tags, and without having to synchronize the archives. Just tell the developer what version he is at. I'm not English native speaker but there are 2 reasons why we may assume that he does not think academic == irrelevant: - quotes around word usually denotes non-literal meaning (in this context) - IIRC that can be used only in defing relative clauses. Therefore he does not think (or he might not think) academic idea have no meaning in real life but those particular ideas. I'm not saying that he's right but he implied much less that it one would assume from quote academic. Regards I think that quotes around the word + structure of sentence (relative clause with that which implies it is non-defining) signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
On 21/04/2011 11:16 PM, John Millikin wrote: My chief complaint is that it's built on patch theory, which is ill-defined and doesn't seem particularly useful. The Bazaar/Git/Mercurial DAG model is much easier to understand and work with. Possibly as a consequence of its shaky foundation, Darcs is much slower than the competition -- this becomes noticeable for even very small repositories, when doing a lot of branching and merging. I think it's been kept alive in the Haskell community out of pure eat our dogfood instinct; IMO if having a VCS written in Haskell is important, it would be better to just write a new implementation of an existing tool. Of course, nobody cares that much about what language their VCS is written in, generally. Ah, how silly of me. I should have known a question like this was highly likely to provoke a flamewar. I had assumed that the way Darcs was is *the definition of* what distributed version control is. So it was a bit of a shock to read about how Git works, and discovered that it does it totally wrong. So I want and read about Mercural and all the others, and discovered that they all do it wrong too. Given that the way Darcs works is so superior to the way everything else works, I was just puzzled as to why even GHC is trying to get rid of it. It seems the answer is some combination of performance issues (I've never seen any) and reliability issues (which again I've never come across). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
I'm a great fan of darcs, and also have never run into the performance and reliability issues that GHC has. That said, it's clear that they *have* run into them, and if something else makes GHC development go more smoothly, then I'm 100% supportive of their using it. It is disappointing, though that (I agree with you here) git and others have a fundamentally bad model for performing the task. They chose that model for pragmatic reasons... it's operationally clearer, even if the meaning of things is a bit more muddled. Making a working znd pragmatic version control system using a darcs-ish model is simply a harder job than doing the same in the git/hg way. I use darcs whenever I can, and think they have done an excellent job by and large; but you won't find a single darcs developer who thinks they have completely accomplished the task. On Apr 23, 2011 5:57 AM, Andrew Coppin andrewcop...@btinternet.com wrote: On 21/04/2011 11:16 PM, John Millikin wrote: My chief complaint is that it's built on patch theory, which is ill-defined and doesn't seem particularly useful. The Bazaar/Git/Mercurial DAG model is much easier to understand and work with. Possibly as a consequence of its shaky foundation, Darcs is much slower than the competition -- this becomes noticeable for even very small repositories, when doing a lot of branching and merging. I think it's been kept alive in the Haskell community out of pure eat our dogfood instinct; IMO if having a VCS written in Haskell is important, it would be better to just write a new implementation of an existing tool. Of course, nobody cares that much about what language their VCS is written in, generally. Ah, how silly of me. I should have known a question like this was highly likely to provoke a flamewar. I had assumed that the way Darcs was is *the definition of* what distributed version control is. So it was a bit of a shock to read about how Git works, and discovered that it does it totally wrong. So I want and read about Mercural and all the others, and discovered that they all do it wrong too. Given that the way Darcs works is so superior to the way everything else works, I was just puzzled as to why even GHC is trying to get rid of it. It seems the answer is some combination of performance issues (I've never seen any) and reliability issues (which again I've never come across). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
On 04/22/11 01:34 AM, Maciej Marcin Piechotka wrote: On Thu, 2011-04-21 at 21:29 +0100, Andrew Coppin wrote: I'm sure this must be a VFAQ, but... There seems to be universal agreement that Darcs is a nice idea, but is unsuitable for real projects. Even GHC keeps talking about getting rid of Darcs. Can anybody tell me what the problems with Darcs actually are? I believe the biggest problem was (i.e. when migration started) that there is no big-name-hosting supporting darcs. When code.haskell.org went down people were cut off from code. http://www.patch-tag.com/ is not enough for you? Cheers, Karel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
Jason Dagit schrieb: * Every commit needs --ask-deps , because the automatic dependency detector can only detect automatic changes (and not things like adding a new function in a different module) You mean it can only detect dependencies that depend on each other with respect to a diff of the changes. Detecting most anything else would be undecidable in the general case. As a divergent data point, I've been using darcs since 2003 and I have yet to use --ask-deps except to learn how it works. I think that other version control systems just assume that a new patch depends on _all_ existing patches. Mentally I am still comparing Darcs with Subversion, that is, what my colleagues use. Thus I am even happy with Darcs-1. :-) Sure, sometimes I have to re-record several patches, when I forgot to download latest patches from a repository before recording my own ones. My rule of thumb is, that I must avoid merges at all costs. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
Maciej I believe the biggest problem was (i.e. when migration started) Maciej that there is no big-name-hosting supporting darcs. When Maciej code.haskell.org went down people were cut off from code. Please forgive me if the answer is obvious : is Darcs storage backend agnostic, or must it really store things in local filesystem ? AFAIK, BitBucket team patched (internally) mercurial to allow storage to amz s3. I don't want to advertise for a particular key-value storage provider, but most of them are quiet reliable and cheap. Designing a hub that would store everything in such a key-value persistent store should not be too hard to get right, reliable and distributed. Hosting it would be cheap also. -- Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
Good chance you've already read this but if not here is a good post by Linus about his take on the problems with darcs: http://markmail.org/message/vk3gf7ap5auxcxnb I personally think he is right on the money here. The other problem with Darcs is performance. While it has improved a lot its still not good enough. When GHC was using darcs you couldn't use the annotate command because it took far too long to run. If you can't use certain features of your vcs because of performance its a big fail. GHC isn't even really that large a code base, imagine trying to use darcs for say the Linux kernel. I also don't think darcs handles branches and merging well enough. Cheers, David On 21 April 2011 13:29, Andrew Coppin andrewcop...@btinternet.com wrote: I'm sure this must be a VFAQ, but... There seems to be universal agreement that Darcs is a nice idea, but is unsuitable for real projects. Even GHC keeps talking about getting rid of Darcs. Can anybody tell me what the problems with Darcs actually are? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
On Thu, 2011-04-21 at 19:39 -0500, Jake McArthur wrote: On Thu, Apr 21, 2011 at 7:31 PM, Maciej Marcin Piechotka uzytkown...@gmail.com wrote: Last time I checked it disallowed my as 5 depended on 4 which depended on 3 which depended on 2 which depended on 1 as all changed x.hs Merely changing the same file is not sufficient for that. In order for Darcs to say patch A depends on patch B they must change the same lines. Or nearby lines... That said, rebase has its uses. It's due in an upcoming version of Darcs, actually. - Jake Great Regards signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
On 4/21/11 10:16 PM, wren ng thornton wrote: rather, what I'd like is someplace to keep my code which also provides a good bugtracker. Unfortunately, neither darcsden nor patchtag offer darcsden does include a simple issue tracker now. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
On 4/22/11 11:39 AM, Simon Michael wrote: On 4/21/11 10:16 PM, wren ng thornton wrote: rather, what I'd like is someplace to keep my code which also provides a good bugtracker. Unfortunately, neither darcsden nor patchtag offer darcsden does include a simple issue tracker now. Ah, excellent. I'll have to take a look again. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
On Thu, Apr 21, 2011 at 1:29 PM, Andrew Coppin andrewcop...@btinternet.comwrote: I'm sure this must be a VFAQ, but... There seems to be universal agreement that Darcs is a nice idea, but is unsuitable for real projects. Even GHC keeps talking about getting rid of Darcs. Can anybody tell me what the problems with Darcs actually are? It's been documented in the GHC discussions, on reddit, and elsewhere. I would encourage you to look at the darcs-users mailing list archives and the ghc archives. My personal summary is as follows: * There is religion/fan-boy-ism around git and in general vcs is subject to network effects. * Github enables a level of collaboration that is hard to get with darcs. Some people say this as: Github is the best thing about git. * Performance concerns (for example, darcs annotate needs too much time/memory). * Conflict merging issues (patch theory has flaws that lead to exponential time merges). Darcs has some additional flaws that people complain about, but which I don't think are core to the issue: * Conflict markers are hard to understand * patches as a set instead of linear history (patch soup complaints) * It's written in Haskell * It's not popular enough * People say they just don't get patch theory I hope that helps, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
My chief complaint is that it's built on patch theory, which is ill-defined and doesn't seem particularly useful. The Bazaar/Git/Mercurial DAG model is much easier to understand and work with. Possibly as a consequence of its shaky foundation, Darcs is much slower than the competition -- this becomes noticeable for even very small repositories, when doing a lot of branching and merging. I think it's been kept alive in the Haskell community out of pure eat our dogfood instinct; IMO if having a VCS written in Haskell is important, it would be better to just write a new implementation of an existing tool. Of course, nobody cares that much about what language their VCS is written in, generally. Beyond that, the feeling I get of the three major DVCS alternatives is: git: Used by Linux kernel hackers, and Rails plugin developers who think they're more important than Linux kernel hackers hg/bzr: Used by people who don't like git's UI, and flipped heads/tails when picking a DVCS (hg and bzr are basically equivalent) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
On Thu, Apr 21, 2011 at 7:16 PM, John Millikin jmilli...@gmail.com wrote: My chief complaint is that it's built on patch theory, which is ill-defined and doesn't seem particularly useful. The Bazaar/Git/Mercurial DAG model is much easier to understand and work with. For me its greatest asset is the patch theory. I find it much easier to understand than git's model. I don't know about hg/bzr, but I guess they have a model similar to git's. So I guess this point is up to debate. =) Cheers, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
Andrew Coppin wrote: I'm sure this must be a VFAQ, but... There seems to be universal agreement that Darcs is a nice idea, but is unsuitable for real projects. I not sure what constitues a real project, but I have found Darcs to be more than satisfactory for Ben Lippmeier's DDC compiler project. Thats 50k lines of Haskell code with a commit history of 2500+ commits. I also do use other VCSs, in order of frequency Bzr, SVN, Git Darcs and Hg. However, my order of preference is Bzr, Darcs, Hg, Git and then SVN. The only reason I slight prefer Bzr over Darcs is that Bzr has a slightly easier and more intuitive (at least for me) user interface. However, I do find Bzr (written in Python) slightly fragile in that I ocassionally get a huge Python backtrace when something blows up Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
John Millikin wrote: My chief complaint is that it's built on patch theory, which is ill-defined and doesn't seem particularly useful. The Bazaar/Git/Mercurial DAG model is much easier to understand and work with. Possibly as a consequence of its shaky foundation, Darcs is much slower than the competition -- this becomes noticeable for even very small repositories, when doing a lot of branching and merging. I have two projects, one has about 50k lines of C code thats kept in Bzr and the other has 50k lines of Haskell code thats kept in Darcs. They both have similar sized commit and branch histories. I find the speed on Bzr and Darcs on those two projects to be pretty much the same. Most operations on a local repo take well less than 5 seconds. Git may be faster but if its under 5 seconds who cares. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
On Thu, Apr 21, 2011 at 3:29 PM, Andrew Coppin andrewcop...@btinternet.com wrote: I'm sure this must be a VFAQ, but... There seems to be universal agreement that Darcs is a nice idea, but is unsuitable for real projects. Even GHC keeps talking about getting rid of Darcs. Can anybody tell me what the problems with Darcs actually are? Yi, a fairly large and old repository, recently moved to (primarily) Git. Our motivation was not flaws in Darcs, but rather GitHub. -- Jeff Wheeler Undergraduate, Electrical Engineering University of Illinois at Urbana-Champaign ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
Um, the patch theory is what makes darcs just work. There is no need to understand it any more than you have to know VLSI design to understand how your computer works. The end result is that darcs repositories don't get corrupted and the order you integrate patches doesn't affect things meaning cherrypicking is painless. I think the main problem with patch theory is with its PR. It is a super cool algorithm and rightly droundy should be proud of it so he highlighted it. I think this caused people to think they had to understand the patch theory rather than just sit back and enjoy it. Incidentally, I wrote a github like site based around darcs a few years ago at codehole.org. It is just used internally by me for certain projects. but if people were interested, I could resume work on it and make it public. John On Thu, Apr 21, 2011 at 3:16 PM, John Millikin jmilli...@gmail.com wrote: My chief complaint is that it's built on patch theory, which is ill-defined and doesn't seem particularly useful. The Bazaar/Git/Mercurial DAG model is much easier to understand and work with. Possibly as a consequence of its shaky foundation, Darcs is much slower than the competition -- this becomes noticeable for even very small repositories, when doing a lot of branching and merging. I think it's been kept alive in the Haskell community out of pure eat our dogfood instinct; IMO if having a VCS written in Haskell is important, it would be better to just write a new implementation of an existing tool. Of course, nobody cares that much about what language their VCS is written in, generally. Beyond that, the feeling I get of the three major DVCS alternatives is: git: Used by Linux kernel hackers, and Rails plugin developers who think they're more important than Linux kernel hackers hg/bzr: Used by people who don't like git's UI, and flipped heads/tails when picking a DVCS (hg and bzr are basically equivalent) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
On Thu, 2011-04-21 at 16:16 -0700, John Meacham wrote: Um, the patch theory is what makes darcs just work. There is no need to understand it any more than you have to know VLSI design to understand how your computer works. The end result is that darcs repositories don't get corrupted and the order you integrate patches doesn't affect things meaning cherrypicking is painless. While I appriciate the patch theory I don't think darcs fits the workflow of at least some people Assume following changes 1. Feature X - file x.hs 2. Feature Y - file y.hs and x.hs 3. Feature Z - file z.hs and x.hs 4. Fix to feature Y (changes x.hs) 5. Fix to feature X (changes x.hs) Now before pushing I would like to have 3 nice commits. In git I can rewrite history by single command: # git rebase -i origin/master and edit the file to look like pick 1 fixup 5 pick 2 fixup 4 pick 3 Manually/automatically check everything is ok. Regards signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
On Thu, 2011-04-21 at 21:29 +0100, Andrew Coppin wrote: I'm sure this must be a VFAQ, but... There seems to be universal agreement that Darcs is a nice idea, but is unsuitable for real projects. Even GHC keeps talking about getting rid of Darcs. Can anybody tell me what the problems with Darcs actually are? I believe the biggest problem was (i.e. when migration started) that there is no big-name-hosting supporting darcs. When code.haskell.org went down people were cut off from code. Regards signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
On Thu, Apr 21, 2011 at 6:32 PM, Maciej Marcin Piechotka uzytkown...@gmail.com wrote: Assume following changes 1. Feature X - file x.hs 2. Feature Y - file y.hs and x.hs 3. Feature Z - file z.hs and x.hs 4. Fix to feature Y (changes x.hs) 5. Fix to feature X (changes x.hs) Now before pushing I would like to have 3 nice commits. In git I can rewrite history by single command: # git rebase -i origin/master and edit the file to look like pick 1 fixup 5 pick 2 fixup 4 pick 3 Manually/automatically check everything is ok. % darcs unrec -a -p 'Fix to feature X' Finished unrecording. % darcs amend -a -p 'Feature X' Thu Apr 21 19:11:54 CDT 2011 Jake McArthur jake.mcart...@gmail.com * Feature X Shall I amend this patch? [yN...], or ? for more options: y Finished amending patch: Thu Apr 21 19:14:41 CDT 2011 Jake McArthur jake.mcart...@gmail.com * Feature X % darcs unrec -a -p 'Fix to feature Y' Finished unrecording. % darcs amend -a -p 'Feature Y' Thu Apr 21 19:12:12 CDT 2011 Jake McArthur jake.mcart...@gmail.com * Feature Y Shall I amend this patch? [yN...], or ? for more options: y Finished amending patch: Thu Apr 21 19:14:50 CDT 2011 Jake McArthur jake.mcart...@gmail.com * Feature Y - Jake ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
On Thu, 2011-04-21 at 19:19 -0500, Jake McArthur wrote: On Thu, Apr 21, 2011 at 6:32 PM, Maciej Marcin Piechotka uzytkown...@gmail.com wrote: Assume following changes 1. Feature X - file x.hs 2. Feature Y - file y.hs and x.hs 3. Feature Z - file z.hs and x.hs 4. Fix to feature Y (changes x.hs) 5. Fix to feature X (changes x.hs) Now before pushing I would like to have 3 nice commits. In git I can rewrite history by single command: # git rebase -i origin/master and edit the file to look like pick 1 fixup 5 pick 2 fixup 4 pick 3 Manually/automatically check everything is ok. % darcs unrec -a -p 'Fix to feature X' Finished unrecording. % darcs amend -a -p 'Feature X' Thu Apr 21 19:11:54 CDT 2011 Jake McArthur jake.mcart...@gmail.com * Feature X Shall I amend this patch? [yN...], or ? for more options: y Finished amending patch: Thu Apr 21 19:14:41 CDT 2011 Jake McArthur jake.mcart...@gmail.com * Feature X % darcs unrec -a -p 'Fix to feature Y' Finished unrecording. % darcs amend -a -p 'Feature Y' Thu Apr 21 19:12:12 CDT 2011 Jake McArthur jake.mcart...@gmail.com * Feature Y Shall I amend this patch? [yN...], or ? for more options: y Finished amending patch: Thu Apr 21 19:14:50 CDT 2011 Jake McArthur jake.mcart...@gmail.com * Feature Y - Jake Last time I checked it disallowed my as 5 depended on 4 which depended on 3 which depended on 2 which depended on 1 as all changed x.hs: Fri Apr 22 02:30:03 CEST 2011 Maciej Piechotka uzytkown...@gmail.com * Y feature Shall I amend this patch? [yN...], or ? for more options: n Skipping depended-upon patch: Fri Apr 22 02:29:27 CEST 2011 Maciej Piechotka uzytkown...@gmail.com * Feature X Cancelling amend since no patch was selected. Regards signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
On Thu, Apr 21, 2011 at 7:31 PM, Maciej Marcin Piechotka uzytkown...@gmail.com wrote: Last time I checked it disallowed my as 5 depended on 4 which depended on 3 which depended on 2 which depended on 1 as all changed x.hs Merely changing the same file is not sufficient for that. In order for Darcs to say patch A depends on patch B they must change the same lines. That said, rebase has its uses. It's due in an upcoming version of Darcs, actually. - Jake ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
+1 to what you said. On 4/21/11 4:16 PM, John Meacham wrote: Incidentally, I wrote a github like site based around darcs a few years ago at codehole.org. It is just used internally by me for certain projects. but if people were interested, I could resume work on it and make it public. John, please do - darcs folks are longing for a really good hub. You're probably aware of patch-tag and darcsden - perhaps you can exceed or reuse those ? Both are good but have maintainers now focussed elsewhere. Running a robust scalable public darcs hub is difficult. I think darcs developers are keen to help anyone working on that. FYI codehole seems access-restricted. -Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
Codehole doesn't sound like a good name. Don't lose stuff in codehole! Sent from my iPhone On Apr 21, 2011, at 7:33 PM, Simon Michael si...@joyful.com wrote: +1 to what you said. On 4/21/11 4:16 PM, John Meacham wrote: Incidentally, I wrote a github like site based around darcs a few years ago at codehole.org. It is just used internally by me for certain projects. but if people were interested, I could resume work on it and make it public. John, please do - darcs folks are longing for a really good hub. You're probably aware of patch-tag and darcsden - perhaps you can exceed or reuse those ? Both are good but have maintainers now focussed elsewhere. Running a robust scalable public darcs hub is difficult. I think darcs developers are keen to help anyone working on that. FYI codehole seems access-restricted. -Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
On Thursday, April 21, 2011 4:16:07 PM UTC-7, John Meacham wrote: Um, the patch theory is what makes darcs just work. There is no need to understand it any more than you have to know VLSI design to understand how your computer works. The end result is that darcs repositories don't get corrupted and the order you integrate patches doesn't affect things meaning cherrypicking is painless. This is how it's *supposed* to work. My chief complaints with PT are: - Metadata about branches and merges gets lost. This makes later examination of the merge history impossible, or at least unfeasibly difficult. - Every commit needs --ask-deps , because the automatic dependency detector can only detect automatic changes (and not things like adding a new function in a different module) - The order patches are integrated still matters (it's impossible for it to not matter), but there's no longer any direct support for ordering them, so large merges become very manual. - If you ever merge in the wrong order, future merges will begin consuming more and more CPU time until the repository dies. Undoing this requires using darcs-fastconvert and performing manual surgery on the export files. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
On Thu, Apr 21, 2011 at 8:42 PM, John Millikin jmilli...@gmail.com wrote: On Thursday, April 21, 2011 4:16:07 PM UTC-7, John Meacham wrote: Um, the patch theory is what makes darcs just work. There is no need to understand it any more than you have to know VLSI design to understand how your computer works. The end result is that darcs repositories don't get corrupted and the order you integrate patches doesn't affect things meaning cherrypicking is painless. This is how it's *supposed* to work. My chief complaints with PT are: - Metadata about branches and merges gets lost. This makes later examination of the merge history impossible, or at least unfeasibly difficult. That's not an issue with patch theory though. Darcs could still track that and I believe some people have been playing with the idea. - Every commit needs --ask-deps , because the automatic dependency detector can only detect automatic changes (and not things like adding a new function in a different module) You mean it can only detect dependencies that depend on each other with respect to a diff of the changes. Detecting most anything else would be undecidable in the general case. As a divergent data point, I've been using darcs since 2003 and I have yet to use --ask-deps except to learn how it works. - The order patches are integrated still matters (it's impossible for it to not matter), but there's no longer any direct support for ordering them, so large merges become very manual. Can you give an example where you need to control the order of the changes in a merge with git/bzr/svn/etc but that it was not possible with darcs? I'm trying to understand what you mean. - If you ever merge in the wrong order, future merges will begin consuming more and more CPU time until the repository dies. Undoing this requires using darcs-fastconvert and performing manual surgery on the export files. Yes, this is true. Exponential merges still exist, although they are relatively rare with a darcs-2 formated repository. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
On 4/21/11 10:33 PM, Simon Michael wrote: +1 to what you said. On 4/21/11 4:16 PM, John Meacham wrote: Incidentally, I wrote a github like site based around darcs a few years ago at codehole.org. It is just used internally by me for certain projects. but if people were interested, I could resume work on it and make it public. John, please do - darcs folks are longing for a really good hub. You're probably aware of patch-tag and darcsden - perhaps you can exceed or reuse those ? Both are good but have maintainers now focussed elsewhere. Agreed. I'd love to see a good code host for darcs. Actually, for my uses, the code hosting itself isn't that important ---since darcs can fabulously be hosted from any http server--- but rather, what I'd like is someplace to keep my code which also provides a good bugtracker. Unfortunately, neither darcsden nor patchtag offer bugtrackers (AFAIK) and neither github, bitbucket, nor googlecode offer darcs. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
