HN user
I'll just add that these days, people should consider using the Darcs bridge instead: http://wiki.darcs.net/DarcsBridgeUsage
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.
It still does.
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.
We're giving local branches a good think http://wiki.darcs.net/Ideas/Branches
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.
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)
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.
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.