[beachy]

Darcs to me is a bit like VHS vs betamax. A superior technology that did not win in the market due to other factors.

Way back in the day we did some due diligence on our source control - at that time CVS - and settled on darcs as the most elegant.

Around the same time Linus created git and the rest is history and eventually darcs went the way of betamax.

[ltbarcly3]

git is the superior technology. If you weren't around back in the day, one of the big problems with version control was how SLOW it was. Changing branches on a moderate sized codebase in SVN took a long time, and SVN was considered quite fast. When we finally got git we couldn't believe it actually did something. Like you would change branches and it would instantly return, and you would scratch your head and double check that the files were different? It was the difference between 30s of your CPU grinding and 45ms. This was so completely frustrating that long before git became dominant we were all using git-svn so at least we wouldn't be forced to use SVN locally, because it was horrible. Darcs was 1000x worse than that.

Darcs was never good enough, not even close. It wasn't even good. It fundamentally failed at the most basic thing required of version control, that you can actually use it to get work done, because it became so slow with even small codebases that you had to give up and switch to SVN. You could have a codebase with 200k lines of code and basic operations would take 30 MINUTES or longer. (not to mention that darcs would lose data, and you could get in situations where conflict resolution was impossible and you would just be stuck and forced to manually fix things outside of VC)

https://en.wikipedia.org/wiki/Darcs#Shortcomings

Darcs was and still is unusable and inferior.

[beachy]

1000x is a bit hyperbolic but I'll admit I had forgotten the purgatory of slow version control. You are correct about that.

[dan-robertson]

Darcs has exponential time merges so there is definitely potential for getting in very slow situations.

[riwsky]

Tired of and a bit amused by the Betamax trope. When VHS debuted with a two hour recording time, Betamax couldn’t hold more than an hour’s worth of video, making it a horrible fit for most films and sports. The workarounds for this involved compromising the picture quality advantage. Beta was also more expensive. This was not some case of being outmarketed, or unlucky: Betamax was worse technology than VHS. And while git’s design leaves much to be desired (which modern VCSs like jj make clear), there is a helluva lot of great technology in it.

[ltbarcly3]

I wanted to point this out also! The entire meme of "better technology that lost in the market" really appeals to a certain kind of person who is somehow always also intolerable.

[woadwarrior01]

Yeah, there was a lot of FUD being spread around Darc's exponential merge corner-case. We were using it with a medium sized codebase (~50k lines) and never encountered that issue. Anyway, we begrudgingly moved to mercurial a few years later and then onto git, further along the road. With every step, the tooling got worse.

[atombender]

I was on a small team using Darcs around 2005-2008, and I was a big fan of it, evangelizing as much as I could.

However, we were constantly hitting the exponential merge conflict bug. Darcs messed up our repo state several times and cost us days of productivity. It had nothing do with the size of the codebase; as far as I remember, all that was needed to trigger the bug was to make a patch that happened to include the same code line change as someone else. It felt ridiculously fragile. As far as I remember, once you hit the bug, your repo was beyond saving. You had to roll back to a backup.

We still stuck by Darcs until around 2009-2010 when it was pretty obvious the writing was on the wall and Git was going to eat the world, in large part thanks to GitHub.

[gre]

It got to the point where I had a darcs commit take more than ten minutes. That's when I stopped using darcs.

[simonmic]

At a certain point darcs was fixed to make the exponential merge case much more rare, though it has never been entirely removed. At least from that point on, it has always been possible to use darcs productively just by avoiding or working around those very conflict-heavy merge scenarios. Regular darcs users internalise those working habits and so rarely encounter the problem in practice.

If you do encounter a slow merge with darcs, the normal practice is to treat that as a mistake, step back and re-do your commits to be less conflicting - not to waste time waiting, ending up with a very slow merge in your history.

The original exponential merge corner case, and subsequent lack of a clear prevention mechanism or even clear description of the issue, has had a big anti-marketing impact, and has probably kept darcs out of the limelight ever since the departure of the original lead developer, despite a small heroic band of maintainers working on it to this day.

[vanviegen]

We were using Darcs on what was then still a small code base and already started running into operations sometimes taking tens of minutes. Not knowing if an operation would end sometime during our lifetime is pretty annoying. Git, though conceptually worse, felt like a breath of fresh air once we migrated.