3 ms·

I wouldn't call darcs ( http://darcs.net/ http://darcs.net/ ) a failure. Darcs development is humming along and 2.11 is nearing release. Gone are the major per

I wouldn't call darcs ( http://darcs.net/ http://darcs.net/ ) a failure. Darcs development is humming along and 2.11 is nearing release. Gone are the major performance issues with exponential merges and more recently, pushing large files. https://www.mail-archive.com/darcs-users@darcs.net/msg18423.html https://www.mail-archive.com/darcs-users@darcs.net/msg18423.... https://www.mail-archive.com/darcs-users@darcs.net/msg18425.html https://www.mail-archive.com/darcs-users@darcs.net/msg18425.... After having used git, darcs is a joy to use.

drostie 12y ago
Git's user interface is awful until you understand how the organic hairball underlying it is organized, at which point you can mostly "get it." Darcs' hand-holding approach to this is a great example of how to do it; Mercurial's also pretty good (for Hg you need about one tutorial and previous SVN experience, or two tutorials, to "get" it). What Darcs really lacks is a good "Tortoise" client for seamless Windows integration. It was tried (last release 8 years ago; I feel like I can safely talk in the past tense about it) but the userbase has not been large enough to sustain it.
lobster_johnson 12y ago
I and my teams used Darcs in two startups around 2005-2007, back just before and after 2.0. When it worked, it was pretty good. Darcs' UI was close to ideal. The interactive record prompt, for example (which git got after a while with the "-p" flag), was great. The way Darcs was able to infer dependencies between commits automatically and treat it more as a "sea of patches" rather than a linear history meant that it was very easy to work with branches. The problem was that as our codebase grew, it increasingly did not work. The infamous exponential conflict problem was just one of several bugs and performance issues that ended up costing us a lot of money in lost productivity. The problem was that when something went wrong, you probably couldn't fix it yourself. The only people who actually understood the internal database — not just the files on disk, but how it all fit together, including the "patch theory" — were the Darcs developers themselves, and not many people except David Roundy actually understood it from top to bottom. The fact that it was written in Haskell (which, at the time, was a lot more obscure than it is today) just made things worse. After a while we also found that the lack of a linear history had major downsides. Patch dependencies meant it was harder to cherry-pick; when you wanted to pick just one commit, it was often impossibly to understand why Darcs wanted to also pick a bunch of unrelated commits along with it, and from there on it got messy (and you increasingly risked bumping into the exponential merge bug). Git's history-rewriting tools cause more conflicts, but are ultimately simpler and easier to understand. Darcs' tragedy is probably that its performance problems burned so many people that they gave up and left it for Git or Mercurial, never to come back. We might have stuck with it longer, if it hadn't been for the aforementioned issues. On the bright side, even if Darcs hadn't had these issues, we probably would never have had a Darcshub.com, and Git would still have beaten the competition.

drostie 12y ago

Git's user interface is awful until you understand how the organic hairball underlying it is organized, at which point you can mostly "get it." Darcs' hand-holding approach to this is a great example of how to do it; Mercurial's also pretty good (for Hg you need about one tutorial and previous SVN experience, or two tutorials, to "get" it). What Darcs really lacks is a good "Tortoise" client for seamless Windows integration. It was tried (last release 8 years ago; I feel like I can safely talk in the past tense about it) but the userbase has not been large enough to sustain it.

lobster_johnson 12y ago

I and my teams used Darcs in two startups around 2005-2007, back just before and after 2.0. When it worked, it was pretty good. Darcs' UI was close to ideal. The interactive record prompt, for example (which git got after a while with the "-p" flag), was great. The way Darcs was able to infer dependencies between commits automatically and treat it more as a "sea of patches" rather than a linear history meant that it was very easy to work with branches. The problem was that as our codebase grew, it increasingly did not work. The infamous exponential conflict problem was just one of several bugs and performance issues that ended up costing us a lot of money in lost productivity. The problem was that when something went wrong, you probably couldn't fix it yourself. The only people who actually understood the internal database — not just the files on disk, but how it all fit together, including the "patch theory" — were the Darcs developers themselves, and not many people except David Roundy actually understood it from top to bottom. The fact that it was written in Haskell (which, at the time, was a lot more obscure than it is today) just made things worse. After a while we also found that the lack of a linear history had major downsides. Patch dependencies meant it was harder to cherry-pick; when you wanted to pick just one commit, it was often impossibly to understand why Darcs wanted to also pick a bunch of unrelated commits along with it, and from there on it got messy (and you increasingly risked bumping into the exponential merge bug). Git's history-rewriting tools cause more conflicts, but are ultimately simpler and easier to understand. Darcs' tragedy is probably that its performance problems burned so many people that they gave up and left it for Git or Mercurial, never to come back. We might have stuck with it longer, if it hadn't been for the aforementioned issues. On the bright side, even if Darcs hadn't had these issues, we probably would never have had a Darcshub.com, and Git would still have beaten the competition.