{"thread":{"id":"8696","subject":"Darcs","startedAt":"2007-06-24T05:32:52Z","lastAt":"2007-06-29T07:13:54Z","messageCount":16,"participants":["Bu Bacoo","Linus Torvalds","Martin Langhoff","Jan Hudec","Theodore Tso","Junio C Hamano","Dan Chokola","Florian Weimer","Josh Triplett","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"45640","messageId":"cecbdd220706232232w77a609faxf0e6b2dc37f0d1f4@mail.gmail.com","threadId":"8696","inReplyTo":null,"subject":"Darcs","fromName":"Bu Bacoo","fromEmail":"bubacoo@gmail.com","sentAt":"2007-06-24T05:32:52Z","receivedAt":"2007-06-24T05:32:52Z","isPatch":false,"sender":{"key":"bubacoo@gmail.com","avatar":"https://gravatar.com/avatar/627d1645e91c661eb38a29b6835534b5fddf055cf28959e87a54240780422e0e?d=mp&s=160"},"body":"Hello guys (girls?)\n\nWhat do you think about darcs?\n\nThere was a lot written/spoken about morons and stupidos around\nthinking in cvs / svn, etc... (what would be the words for dudes\naround vss ....).\n\nBut not a lot of darcs, even if there are tools like Darcs-Git, etc...\nAre git and darcs supposed to extend each other? Or?\nThe patch algebra in Darcs looks to me pretty similar to Linuse's\npatch-SCM used for kernel bellow 2.6.12.something?\n\nThanks for opinions.\n\nBu\n"},{"id":"45681","messageId":"alpine.LFD.0.98.0706241030540.3593@woody.linux-foundation.org","threadId":"8696","inReplyTo":"cecbdd220706232232w77a609faxf0e6b2dc37f0d1f4@mail.gmail.com","subject":"Re: Darcs","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-06-24T17:59:52Z","receivedAt":"2007-06-24T17:59:52Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 24 Jun 2007, Bu Bacoo wrote:\n> \n> What do you think about darcs?\n> \n> There was a lot written/spoken about morons and stupidos around\n> thinking in cvs / svn, etc... (what would be the words for dudes\n> around vss ....).\n\nAhh, a chance to flame! I will never back down from such a challenge!\n\nDarcs is .. umm .. ehh..\n\n\"Academic\".\n\nOk, I realize that's a pretty weak flame, and I'm sorry. It's not that \ndarcs users are \"stupid\" or \"complete morons\" or \"donkey turds with arms \nand legs\", it's just that the whole project is centered around some \nacademic ideas that have absolutely no relevance in real life, and that \njust don't work in practice.\n\nIn other words, it's a fun project, but it's largely irrelevant. The whole \nunderpinning of darcs (\"everything is a collection of patches\" and the \n\"patch algebra\") is kind of interesting, but it's irrelevant. The thing it \nsolves is not the thing you want solved, and you really don't want to \nhandle conflicts at a \"patch\" level.\n\nI personally think darcs is closer to a smart \"quilt\" than a \"final\" SCM. \nIt's good for keeping track of patches, but let's face it, if you have \nreally big changes, you don't want to handle them the way darcs does.\n\nAnd in that sense, I do think the two approaches can _complement_ each \nother. A lot of people use quilt (or quite often, something similar, based \non a SCM in the background: git has and stgit and guilt, hg has \"mercurial \nqueues\"). And it's absolutely true that you want to have a \"fluid\" level \ntoo, and darcs can do that. \n\nBut you do *not* want to do the whole project history that way. At some \npoint, you need something that works at another level than patch queues. \nDarcs itself kind of has something like this with \"checkpointing\", but the \nfact is, git is just better at this.\n\nSo it basically boils down to the fact that I don't think darcs solves the \nreal problems, and won't scale up. It's versioning model seems *totally* \nbroken, for example. \n\nFundmantal example: somebody has a problem/bug. Tell me how to tell a \ndeveloper what his exact version is - without creating new tags, and \nwithout having to synchronize the archives. Just tell the developer what \nversion he is at.\n\nIn git, you just give a revision number. In darcs, what the *hell* do you \ndo? And that's a pretty damn fundamental operation for a source control \nmanagement setup! As far as I know, darcs only has patch identities.\n\n\t\t\tLinus\n"},{"id":"45691","messageId":"46a038f90706241345m4b5ecb80p9f4ec840993023e0@mail.gmail.com","threadId":"8696","inReplyTo":"alpine.LFD.0.98.0706241030540.3593@woody.linux-foundation.org","subject":"Re: Darcs","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-06-24T20:45:57Z","receivedAt":"2007-06-24T20:45:57Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 6/25/07, Linus Torvalds wrote:\n> Ahh, a chance to flame! I will never back down from such a challenge!\n>\n> Darcs is .. umm .. ehh..\n>\n> \"Academic\".\n\nOTOH, and from the POV of someone closely following the SCM tools in\nthe last few years (and using almost all of them), darcs was the first\nusable DSCM in the camp. I am not sure how much of its commandline\nuser interface was borrowed from BK or elsewhere, but darcs was\n_easy_, where Arch was extremely hard to use.\n\nThe darcs commandset (init, push, pull) is what git, hg and bzr have\ntoday in common. At least _I_ learned about how it could be easy by\nwatching people use Darcs (and feeling very ashamed of my baroque Arch\nusage). The focus on patch tracking (as opposed to \"snapshot\"\ntracking) and the whole patch algebra are two misfires I'd say.\nSnapshot-tracking DSCMs are winning (faster and fundamentally more\nreliable), and the patch algebra doesn't quite scale and (as far as\nI've heard) sometimes ends in unsolvable corner cases.\n\nAnd the closer we get to Darcs UI the happier I feel ;-)\n\ncheers,\n\n\nmartin\n"},{"id":"45694","messageId":"20070624211952.GA3044@efreet.light.src","threadId":"8696","inReplyTo":"46a038f90706241345m4b5ecb80p9f4ec840993023e0@mail.gmail.com","subject":"Re: Darcs","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-06-24T21:19:52Z","receivedAt":"2007-06-24T21:19:52Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Mon, Jun 25, 2007 at 08:45:57 +1200, Martin Langhoff wrote:\n> On 6/25/07, Linus Torvalds wrote:\n> >Ahh, a chance to flame! I will never back down from such a challenge!\n> >\n> >Darcs is .. umm .. ehh..\n> >\n> >\"Academic\".\n\n> OTOH, and from the POV of someone closely following the SCM tools in\n> the last few years (and using almost all of them), darcs was the first\n> usable DSCM in the camp. I am not sure how much of its commandline\n> user interface was borrowed from BK or elsewhere, but darcs was\n> _easy_, where Arch was extremely hard to use.\n\nArch is not in fact distributed. One key feature that makes things\ndistributed is that object (revision in SCM) identity is independent of their\nlocation (repository in SCM). And in Arch that is not true.\n\nRevisions independent of repositories (and branches) is what makes the ad-hoc\nbranching, that makes git (and hg, bazaar and darcs) so easy, possible. Arch\nclaimed to have easy branching, but it was still the old explicit model.\n\n(Besides yes, I can confirm that Arch was not the easiest thing to use.)\n\n> The darcs commandset (init, push, pull) is what git, hg and bzr have\n> today in common. At least _I_ learned about how it could be easy by\n> watching people use Darcs (and feeling very ashamed of my baroque Arch\n> usage). The focus on patch tracking (as opposed to \"snapshot\"\n> tracking) and the whole patch algebra are two misfires I'd say.\n> Snapshot-tracking DSCMs are winning (faster and fundamentally more\n> reliable), and the patch algebra doesn't quite scale and (as far as\n> I've heard) sometimes ends in unsolvable corner cases.\n\nIMHO the patch algebra also falls short of it's goal. The idea is supposed to\nbe that you can cherry-pick easily. However, in practice many changes that\nare easy to cherry-pick are textually dependent in something like import\nlist, list of files in makefile or such. While git cherry-pick will happily\napply such patch and give you a single easy to resolve conflict, darcs will\njust insist on pulling the other patch as well.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"45697","messageId":"20070624215216.GA3910@thunk.org","threadId":"8696","inReplyTo":"46a038f90706241345m4b5ecb80p9f4ec840993023e0@mail.gmail.com","subject":"Re: Darcs","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-06-24T21:52:23Z","receivedAt":"2007-06-24T21:52:23Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Mon, Jun 25, 2007 at 08:45:57AM +1200, Martin Langhoff wrote:\n> OTOH, and from the POV of someone closely following the SCM tools in\n> the last few years (and using almost all of them), darcs was the first\n> usable DSCM in the camp. I am not sure how much of its commandline\n> user interface was borrowed from BK or elsewhere, but darcs was\n> _easy_, where Arch was extremely hard to use.\n\n> The darcs commandset (init, push, pull) is what git, hg and bzr have\n> today in common. \n\n> And the closer we get to Darcs UI the happier I feel ;-)\n\nDarcs was first announced in April 2003 [1].\n\nLinus first started using BK to manage the Linux source tree in 2002;\nI first started using Bitkeeper to manage e2fsprogs back in 2001; and\nBK was first available in late 1998.\n\nSo to give credit where credit is due, the whole \"$foo init\", \"$foo\ncommit\", \"$foo push\", \"$foo pull\" DSCM UI was first pioneered by Larry\nMcVoy and BitKeeper, not Darcs.\n\n\t\t\t\t\t\t- Ted\n\n[1] http://www.haskell.org/pipermail/haskell-cafe/2003-April/004139.html\n"},{"id":"45704","messageId":"7vlke9ouv8.fsf@assigned-by-dhcp.cox.net","threadId":"8696","inReplyTo":"46a038f90706241345m4b5ecb80p9f4ec840993023e0@mail.gmail.com","subject":"Re: Darcs","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-06-24T22:22:51Z","receivedAt":"2007-06-24T22:22:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Martin Langhoff\" writes:\n\n>> \"Academic\".\n>\n> OTOH, and from the POV of someone closely following the SCM tools in\n> the last few years (and using almost all of them), darcs was the first\n> usable DSCM in the camp. I am not sure how much of its commandline\n> user interface was borrowed from BK or elsewhere, but darcs was\n> _easy_, where Arch was extremely hard to use.\n\nI second this. Before I started contributing to git in its\nearly weeks, I staged my own changes to my day-job project in\ndarcs to trickle them in to the company's central repository (I\nwas sufficiently faster than other members of the project and I\nhad to pace myself). \n\nIt would have been much more difficult for me to grasp the basic\nconcepts of how \"distributed development\" process works, if I\ndid not have an exposure to Darcs before I started, especially\nbecause I never used BK.\n"},{"id":"45714","messageId":"alpine.LFD.0.98.0706241618490.3593@woody.linux-foundation.org","threadId":"8696","inReplyTo":"46a038f90706241345m4b5ecb80p9f4ec840993023e0@mail.gmail.com","subject":"Re: Darcs","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-06-24T23:21:05Z","receivedAt":"2007-06-24T23:21:05Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 25 Jun 2007, Martin Langhoff wrote:\n> \n> The darcs commandset (init, push, pull) is what git, hg and bzr have\n> today in common.\n\nI really think the credit goes to BK, not darcs. \n\nBK is why a lot of git commands look like they do: I didn't want to \nre-implement BK, but I definitely wanted to reimplement the flow. At least \nfor common stuff.\n\nThe fact that darcs may have been more usable than other open source scm's \nsays more about the other open source scm's than it says about darcs. \n\narch/tla in particular was (is?) horribly messy. I tried to look at it \nbefore starting git, but even just a cursory look convinced me to look \naway..\n\n\t\tLinus\n"},{"id":"45718","messageId":"61e816970706241640x181038f6s2e41f381af2c785d@mail.gmail.com","threadId":"8696","inReplyTo":"61e816970706241638j60830741p2cd1a102a72ae226@mail.gmail.com","subject":"Re: Darcs","fromName":"Dan Chokola","fromEmail":"dan@chokola.com","sentAt":"2007-06-24T23:40:35Z","receivedAt":"2007-06-24T23:40:35Z","isPatch":false,"sender":{"key":"dan@chokola.com","avatar":null},"body":"Resent to the mailing list because my crappy mail client defaulted to\nHTML. Sorry.\n---------- Forwarded message ----------\nFrom: Dan Chokola \nDate: Jun 24, 2007 7:38 PM\nSubject: Re: Darcs\nTo: Junio C Hamano \nCc: Martin Langhoff , Linus Torvalds\n, Bu Bacoo ,\ngit@vger.kernel.org\n\nOn 6/24/07, Junio C Hamano wrote:\n> \"Martin Langhoff\" writes:\n>\n> >> \"Academic\".\n> >\n> > OTOH, and from the POV of someone closely following the SCM tools in\n> > the last few years (and using almost all of them), darcs was the first\n> > usable DSCM in the camp. I am not sure how much of its commandline\n> > user interface was borrowed from BK or elsewhere, but darcs was\n> > _easy_, where Arch was extremely hard to use.\n>\n> I second this. Before I started contributing to git in its\n> early weeks, I staged my own changes to my day-job project in\n> darcs to trickle them in to the company's central repository (I\n> was sufficiently faster than other members of the project and I\n> had to pace myself).\n>\n> It would have been much more difficult for me to grasp the basic\n> concepts of how \"distributed development\" process works, if I\n> did not have an exposure to Darcs before I started, especially\n> because I never used BK.\n\nThis is an interesting thread. My own background with Git is that it's\nthe first SCM I've ever used. And it comes from XMMS2 being the first\nopen-source project I ever contributed back to. I joined shortly after\nthe kernel (and XMMS2 team, likewise) had switched from BitKeeper to\nGit. So, as Linus said in his tech talk, \"My brain didn't rot from\nyears of thinking CVS was doing something sane,\" and now I can't\nimagine ever using a centralized SCM.\n\nThe interesting thing is that now I'm learning about all the other\ndistributed SCMs (most of which came before Git) now, after having\nlearned Git, so my experience is backwards from a lot of you. When I\nfirst started, had I known about something like darcs, I probably\nwould have loved it much more than git, which was only usable to the\nhighest-level minds at first. I had to use cogito for almost\neverything. But now it's as easy to use as its distributed friends and\nso I don't think ease of use is much of an issue for anyone anymore.\n\nWhat I have noticed is a lot of nitpicking, of which I'm guilty, too.\nThe issue Linus brought up about Darcs and versioning is not one I\ntypically see surface in real life. Users usually complain about some\n_release_ version or, \"I updated last week.\" The maintainer's reply is\nalmost always, \"Between (release x.x.x|last week) and now we fixed\nthat problem, check out the latest source.\" While it could certainly\nget annoying when trying to track down a very specific version, it's\nnot a make-or-break issue that's going to cause anyone to drop Darcs\nand flock to Git.\n\nI also saw another developer become upset about using Git over\nMercurial partly because of the lack of documentation on things like\nthe pack formats. And my own nitpick is that I would never use\nMercurial because it's slow and in Python (a language I despise). The\ntruth is there's a huge feature overlap between Git an Mecurial (as\nwell as Darcs and others) and the fundamental stuff remains constant.\nIn fact, I managed to clone, update, and diff some changes with\nmercurial without ever reading any documentation.\n\nJust thought I'd throw my observations in the ring instead of lurking\non the list. We'll see if any of it is relevant. :)\n\n-Daniel \"Puzzles\" Chokola\n"},{"id":"45720","messageId":"alpine.LFD.0.98.0706241657540.3593@woody.linux-foundation.org","threadId":"8696","inReplyTo":"61e816970706241638j60830741p2cd1a102a72ae226@mail.gmail.com","subject":"Re: Darcs","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-06-25T00:00:33Z","receivedAt":"2007-06-25T00:00:33Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 24 Jun 2007, Dan Chokola wrote:\n> \n> What I have noticed is a lot of nitpicking, of which I'm guilty, too. The\n> issue Linus brought up about Darcs and versioning is not one I typically see\n> surface in real life. Users usually complain about some _release_ version\n> or, \"I updated last week.\"\n\nActually, in the kernel, we are getting quite a lot out of \"git bisect\", \nand people throw git SHA1's around to describe where they are, or a \nparticular commit.\n\nWhich never happened with BK.\n\nSo I think that the _ability_ to name revisions easily across different \nuses is quite important, because it then drives behaviour.\n\nWithout it, you'll never notice you need it. With it, you start wondering \nhow others handle it.\n\nFor example, we have people like Andrew, who don't really \"use\" git, and \nhe starts pointing to commits with their git ID, because he sees them \nflying past, and he knows they are stable and useful for things like \ngitweb.\n\n\t\t\tLinus\n"},{"id":"45728","messageId":"61e816970706242144y5dd07464ue6b06478a5920699@mail.gmail.com","threadId":"8696","inReplyTo":"alpine.LFD.0.98.0706241657540.3593@woody.linux-foundation.org","subject":"Re: Darcs","fromName":"Dan Chokola","fromEmail":"dan@chokola.com","sentAt":"2007-06-25T04:44:15Z","receivedAt":"2007-06-25T04:44:15Z","isPatch":false,"sender":{"key":"dan@chokola.com","avatar":null},"body":"On 6/24/07, Linus Torvalds wrote:\n> On Sun, 24 Jun 2007, Dan Chokola wrote:\n> >\n> > What I have noticed is a lot of nitpicking, of which I'm guilty, too. The\n> > issue Linus brought up about Darcs and versioning is not one I typically see\n> > surface in real life. Users usually complain about some _release_ version\n> > or, \"I updated last week.\"\n>\n> Actually, in the kernel, we are getting quite a lot out of \"git bisect\",\n> and people throw git SHA1's around to describe where they are, or a\n> particular commit.\n>\n> Which never happened with BK.\n>\n> So I think that the _ability_ to name revisions easily across different\n> uses is quite important, because it then drives behaviour.\n>\n\nI wholeheartedly agree it's important as far as the big picture of SCM\nis concerned. Though I will say that the kernel development is an\nextreme case, where there's a huge number of developers and incredibly\nfast development where matching features are needed from the SCM. And\nI love how Git is born out of this extreme case, as it leads to a lot\nof great features that often scale down, too. But some of them matter\nless to, say, a small, well-integrated team of 5 or 10 people. And an\nidealistic model like the one offered by Darcs might even work better\nthere since corner cases don't show up often.\n\nI'm spoiled by Git and the fact that it has these great abilities and\nfeatures that set it apart, and I'd love everyone to use it. But I'd\nlike people to know that many attributes of Git and other DSCMs don't\ndiffer all that much. (Please don't call me ugly and stupid. ;) And\nactually, this is something of a selling point, because it makes it\nGit seem cozy and familiar.\n\nSo, relating back to the original post, and extending on Linus'\n'academic' analogy, Darcs is like a thesis project from university\nthat proves how DSCM can be done scientifically. Git is grown-up Darcs\nthat proves how DSCM can be done practically. The bottom line is the\nfoundations of DSCM, cheap branching, easy merging, and the like, can\nbe done very similarly in either Darcs or Git, so moving from one to\nthe other leaves you with a largely familiar set of commands.\n\n> Without it, you'll never notice you need it. With it, you start wondering\n> how others handle it.\n>\n\nGit really does have a way of spoiling its users (I don't know how\nCVS/SVN users live), no argument here.\n\n-Daniel \"Puzzles\" Chokola\n"},{"id":"45763","messageId":"87vedcqna7.fsf@mid.deneb.enyo.de","threadId":"8696","inReplyTo":"cecbdd220706232232w77a609faxf0e6b2dc37f0d1f4@mail.gmail.com","subject":"Re: Darcs","fromName":"Florian Weimer","fromEmail":"fw@deneb.enyo.de","sentAt":"2007-06-25T11:36:00Z","receivedAt":"2007-06-25T11:36:00Z","isPatch":false,"sender":{"key":"fw@deneb.enyo.de","avatar":null},"body":"* Bu Bacoo:\n\n> What do you think about darcs?\n\nThe UI is nice, but darcs is quite slow (even if you don't hit the\nexponentional corner case in the merge algorithm).\n\nMy main gripe with darcs, and the prime reason why I'm moving away\nfrom it, is its lack of support for software archaeology. If you\nhaven't tagged a tree at some point, you'll face lots of trouble when\nyou try to restore something that resembles the tree you had back\nthen. This is a direct consequence of the \"heap of patches\" approach,\nbut it's a real nuisance, and the benefits of the increased\nflexibility don't make up for it, IMHO.\n"},{"id":"45780","messageId":"cecbdd220706250954m6ce18fcem6cae4729e795e947@mail.gmail.com","threadId":"8696","inReplyTo":"87vedcqna7.fsf@mid.deneb.enyo.de","subject":"Re: Darcs","fromName":"Bu Bacoo","fromEmail":"bubacoo@gmail.com","sentAt":"2007-06-25T16:54:00Z","receivedAt":"2007-06-25T16:54:00Z","isPatch":false,"sender":{"key":"bubacoo@gmail.com","avatar":"https://gravatar.com/avatar/627d1645e91c661eb38a29b6835534b5fddf055cf28959e87a54240780422e0e?d=mp&s=160"},"body":"Florian, what are you moving to? To GIT?\n\nOn 6/25/07, Florian Weimer wrote:\n> * Bu Bacoo:\n>\n> > What do you think about darcs?\n>\n> The UI is nice, but darcs is quite slow (even if you don't hit the\n> exponentional corner case in the merge algorithm).\n>\n> My main gripe with darcs, and the prime reason why I'm moving away\n> from it, is its lack of support for software archaeology. If you\n> haven't tagged a tree at some point, you'll face lots of trouble when\n> you try to restore something that resembles the tree you had back\n> then. This is a direct consequence of the \"heap of patches\" approach,\n> but it's a real nuisance, and the benefits of the increased\n> flexibility don't make up for it, IMHO.\n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n>\n"},{"id":"45861","messageId":"46a038f90706261700g7b1791d7r5413d0b289421122@mail.gmail.com","threadId":"8696","inReplyTo":"61e816970706242144y5dd07464ue6b06478a5920699@mail.gmail.com","subject":"Re: Darcs","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-06-27T00:00:48Z","receivedAt":"2007-06-27T00:00:48Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 6/25/07, Dan Chokola wrote:\n> So, relating back to the original post, and extending on Linus'\n> 'academic' analogy, Darcs is like a thesis project from university\n> that proves how DSCM can be done scientifically. Git is grown-up Darcs\n> that proves how DSCM can be done practically.\n\nI don't think it's like that. More like\n\n - BK showed it's done\n - Darcs picked some good bits from BK (while no other foss dscm did\nuntil git/hg/bzr came along) but got distracted with interesting but\nnot-that-useful stuff - see patch algebra.\n\ncheers,\n\n\nm\n"},{"id":"45941","messageId":"46830E60.2090806@freedesktop.org","threadId":"8696","inReplyTo":"alpine.LFD.0.98.0706241030540.3593@woody.linux-foundation.org","subject":"Re: Darcs","fromName":"Josh Triplett","fromEmail":"josh@freedesktop.org","sentAt":"2007-06-28T01:26:56Z","receivedAt":"2007-06-28T01:26:56Z","isPatch":false,"sender":{"key":"josh@joshtriplett.org","avatar":"https://avatars.githubusercontent.com/u/162737?v=4"},"body":"Linus Torvalds wrote:\n> On Sun, 24 Jun 2007, Bu Bacoo wrote:\n>> What do you think about darcs?\n>>\n>> There was a lot written/spoken about morons and stupidos around\n>> thinking in cvs / svn, etc... (what would be the words for dudes\n>> around vss ....).\n> \n> Ahh, a chance to flame! I will never back down from such a challenge!\n> \n> Darcs is .. umm .. ehh..\n\nWow. You completely skipped the opportunity to flame Visual Source Safe (vss)\nusers. :) Too easy?\n\n- Josh Triplett\n\n\n"},{"id":"45977","messageId":"Pine.LNX.4.64.0706281401410.4438@racer.site","threadId":"8696","inReplyTo":"46830E60.2090806@freedesktop.org","subject":"Re: Darcs","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-06-28T13:02:06Z","receivedAt":"2007-06-28T13:02:06Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 27 Jun 2007, Josh Triplett wrote:\n\n> Wow. You completely skipped the opportunity to flame Visual Source Safe \n> (vss) users. :) Too easy?\n\nIt's no fun if the targets of your ridicule don't even get it.\n\nCiao,\nDscho\n"},{"id":"46031","messageId":"cecbdd220706290013s66486922pc28bfc0f5a89be62@mail.gmail.com","threadId":"8696","inReplyTo":"46830E60.2090806@freedesktop.org","subject":"Re: Darcs","fromName":"Bu Bacoo","fromEmail":"bubacoo@gmail.com","sentAt":"2007-06-29T07:13:54Z","receivedAt":"2007-06-29T07:13:54Z","isPatch":false,"sender":{"key":"bubacoo@gmail.com","avatar":"https://gravatar.com/avatar/627d1645e91c661eb38a29b6835534b5fddf055cf28959e87a54240780422e0e?d=mp&s=160"},"body":"On 6/28/07, Josh Triplett wrote:\n> Linus Torvalds wrote:\n> > On Sun, 24 Jun 2007, Bu Bacoo wrote:\n> >> What do you think about darcs?\n> >>\n> >> There was a lot written/spoken about morons and stupidos around\n> >> thinking in cvs / svn, etc... (what would be the words for dudes\n> >> around vss ....).\n> >\n> > Ahh, a chance to flame! I will never back down from such a challenge!\n> >\n> > Darcs is .. umm .. ehh..\n>\n> Wow. You completely skipped the opportunity to flame Visual Source Safe (vss)\n> users. :) Too easy?\n>\n> - Josh Triplett\n>\n>\n>\n>\n\nWe've been talking about version control systems, not version killers.... ;)\n"}]}