"Another" could imply that Darcs is new, but it's not. According to Wikipedia, the first release was in 2003.
We tried using Darcs at work in 2006, but the early exponential merge issues made it impossible to use. (One time, we let Darcs try to merge "some changes" over the weekend, but it never completed.) Unfortunately we chose Subversion instead.
I tried using Darcs at work for a fairly large codebase (2.5M LOC), in 2006/2007. It was a disaster. Not only did we run into exponential merge issues, but we also had corruption problems.
I loved it for small repos and my private work, but it just wasn't ready for larger code bases. Perhaps it is now, but in the meantime git got much, much better and I'm not looking to switch back.
Hi, I'm very sorry about your bad experience with Darcs, and am happy that Git is working out for you. I very much admire the Git infrastructure and hope that someday Darcs can catch up or even slowly worm its way into Git again. We tend to recommend it for smaller teams and personal projects these days.
Darcs got too popular too early and was hurt for it (although then again, its relative popularity at the time was also a good way for us to ferret out issues). We've now shrunk back to a more reasonable size (which makes it a bit harder to keep going, but takes off some of the pressure too, double-edged)
Don't be sorry — I didn't pay any money for it and it was my decision :-)
I think darcs suffered because it set high expectations. I remember being fascinated with the "theory of patches". The web site looked very promising. And it was written in Haskell, so it had to be correct, right? :-)
I liked the simplicity of the command-line interface of darcs. I just never looked around for 1M+ LOC projects using it on a daily basis. I should have been more careful.
I still use darcs for a number of small things and I'm happy with it. I'm happier with Git, mostly because of its practical approach and the freedom it offers ("text is just text" and "you own your history, do whatever you want to it").
Yep it had a problem where the whole repository could be come corrupt and impossible to repair IIRC. Kind of a deal breaker unfortunately as a consistent repo is a #1 prio when shopping for a VCS.
Does git-svn now handle svn:externals properly? I can't find anything saying it now has support. I'd love to switch to git as my client, but we have upwards of 70 externals for libraries we maintain, and converting those to git submodules is not an option. Well it is, but it is far more work than simply using git as a client.
I don't think Git submodules were added until 2009 (at least that's what the commit history looks like). We deployed with SVN at least six years ago, long before git could compete.
Still, I would like to use git as my svn client, but it's just not a suitable replacement without externals handled nicely.
I had some merge problems with SVN too (like a 6 hour merge session twice a year), but that may be due to my limited SVN knowledge and poor branch setup.
As an aside, I changed jobs to another place using SVN, and when they started moving to Git I changed jobs again. Still using SVN! :-)
We tried using Darcs at work in 2006, but the early exponential merge issues made it impossible to use. (One time, we let Darcs try to merge "some changes" over the weekend, but it never completed.) Unfortunately we chose Subversion instead.