We've made a lot of progress. You'll see people saying that their performance problems have gone away. But we have a long way to go.
Two things to fix: downloading repos is slow (latency, too many small files); and conflict merging can be slow under a few cases. The first one we have a fix for from a summer of code project, but needs more work. The second issue is a very deep, very serious, and will take us a seriously long time to think through.
I suspect there was less pressure for local branching because a lot of things you tend to want to do with branching, Darcs sort of trivially does with its easy cherry picking. But there are cases where cherry picking won't be enough and you want to have the separation, and it those cases, I can see where people would want to share working directories.
As one Darcs hacker among several (meaning I want it to be clear I'm not speaking for the rest of the team), the most important thing about Darcs is the friendly UI [and the friendly UI is made possible by the patch theory stuff]. And so my concern in trying to do Darcs branches is to do them in a way that keeps the UI very simple to learn and explore. We'll get there. Slowly.
Even without shared working directories, with the current branch as a dir workflow, you have no easy way to see what branches you have, how they relate, nor to express how they should relate (which one should follow which other one). For instance, this means that if I open a new branch on my public repository, there's no automated way for people pulling from my older branch to notice that fact. To me, it is a more compelling but rarely stated argument for in-vcs branching.
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").
I look forward to Darcs being more and more worthy for Git to steal ideas from. I've spoken with an occasional Git hacker, doing a bit of minor evangelism. Hopefully we'll see more work in that direction. It's about developing and sharing good ideas. Software is incidental. If Git becomes way nicer to use as a result of Darcs existing, I'm a happy hacker.
Hi all! As a Darcs developer (mostly cheerleader), I'd like to make a general comment that Darcs should be seen more as a version control system we're trying to build than one you should use right away. Please keep an eye on it if you're interested in the idea, but don't encourage your boss to use it just yet :-)
It's made a lot of progress over the years, and works great for my needs, but we do still have serious bugs and performance problems we need to sort through; and yes still lacks a lot of critical tooling/infrastructure around it.
We love what we do, and think that we have something new to bring to the table (among other things, making it easy to pinpoint commits that you want to pull, delete, etc; DVCS'es may all do some cherry picking ala git add -p, but Darcs makes it possible to use it everywhere), but it may take us a very long time to get to stage where we can responsibly talk about it.
There lot's of work to do, lots.
If you're looking into getting to some Haskell hacking, consider Darcs as a good side project to get into. We can use you.
I'm a Darcs user and occasional contributor. I have been using it continuously on small-medium projects to my great benefit since at least 2004. Now we have just released 2.8, the developer community has been growing, and sure Darcs has its problems but so does every VCS. We also have unique strengths. Is it really necessary to still be saying "we're not ready" and "don't use it yet" ?
I would like to see hard data and experience reports of where Darcs worked and didn't work for people, instead (so I'm loving this thread.) Here are a couple of repos I've worked with:
- hledger: 2477 patches, 251 files, 66M, 5 years of activity
- Zwiki 0.x: 1897 patches, 295 files, 12M, 5 years
- Darcs: 10171 patches, 731 files, 51M, 10 years
- GHC before it moved: 23413 patches, 1353 files, 162M, 5 years (+ 10 years of converted history)
Hi! I'm sorry this isn't any easier yet. In Darcs, one approximation of this sort of thing is to take the whole history (sequence of patches) and hash that. Unfortunately, this approach fails to recognise different darcs-allowed patch orders as having the same history. It's fine as a conservative default, but we'd like something better. See [short secure ID](http://wiki.darcs.net/Ideas/ShortSecureId) for some thinking about the problem.
It's not ready for bi-directional incremental bridging, but for one shot conversions, it should be just fine.
The Darcs bridge uses the Darcs library to do things and understands Darcs better.