8 ms·

Darcs - Another open source version control system

92 points by alagu 14y ago

rdtsc 14y ago
The Cambrian Explosion of the distributed version control system has passed I think. Git seems to come out ahead. I think it would be easier to just switch to it. I like Bazaar and used Hg, but this is tool used to collaborate with others (unlike say an editor) so picking a tool that others know and use is important in a team. Darcs has an interesting approach, sure, but that is not enough for it to win mind-share, and I wouldn't spend time looking at bit because I will have a very hard time getting others to do the same. Also the excitement and euphoria about learning and experimenting with distributed VCs is passed. I feel, for most they have stopped having the "wow" factor and became just a tool in the same category as patch, diff, less and tar.
- tav 14y ago
  It's a sad day, the day a hacker refuses to look at something because they'd "have a very hard time getting others to do the same". By that same token we should avoid looking at the likes of Haskell, Erlang, Rust, etc. You are absolutely right that Git has come out on top, but Darcs definitely merits a look at least. For what it's worth, I was in the Monotone [1] camp against Darcs back in the day... :) [1] http://en.wikipedia.org/wiki/Monotone_(software) http://en.wikipedia.org/wiki/Monotone_(software)
  - skrebbel 14y ago
    This. Surely git "has won", but you'd be fitted with a pretty bad sense of history if you think that this is forever. Thus, it definitely does not hurt to keep Darcs in view. I bet that if any version control system is going to replace git, it'll look at least as much like Darcs as anything else. I'm no expert by a long shot, but to me it appears that if we're going to try to finally make version control user-friendly, something inspired by Darcs' patch algebra may well be at the base of it. While Darcs is impractical for a whole set of use cases, it's very practical for a whole other set of use cases.
    - qznc 14y ago
      It will be very hard for Darcs (and Bazaar, Monotone, etc.) to get so much better than git that switching is worth it. Just a better theoretical base for some edge cases is not enough. Hg has also quite some mindshare. I consider it the only DVCS, which still seriously competes with Git. Apart from that, there are niche groups: Haskell with Darcs, Ubuntu with Bazaar.
      - skrebbel 14y ago
        > Just a better theoretical base for some edge cases is not enough. That's why I said "user friendliness". Even on a superficial level, Git is enormously lacking in this aspect. More fundamentally, the way moving changes around between branches works in Darcs is significantly simpler and "hey, it read my mind!" than in Git, where you need to understand the underlying object model and the tools very well to do this well. Sure, many other things are a disaster in Darcs, but I'm not saying Darcs will replace Git. I'm saying something inspired by it well.
      - durin42 14y ago
        > It will be very hard for Darcs (and Bazaar, Monotone, etc.) to get so much better than git that switching is worth it. People said this about Subversion not so long ago.
      - SkyMarshal 14y ago
        Fwiw he didn't say Darcs will replace git, he said that whatever eventually replaces git will likely implement some of Darcs best features like the patch algebra. Hence, it's worth taking a little time to actually understand those features, even if you never use darcs. Plus the mental exercise and learning something new is valuable in and of itself.
  - davidw 14y ago
    It's just being cognizant that VC software has positive network externalities. If you want to play with stuff, sure, go ahead, but if vc systems are just part of your toolset, then git has probably won. I'm in the latter camp: I want something solid and dependable - I'd rather spend my experimentation time with a new programming language or something else.
  - rdtsc 14y ago
    > By that same token we should avoid looking at the likes of Haskell, Erlang, Rust, etc I think it is good to periodically evaluate the tools used. And initially there was quite a bit of excitement around DVCS and everyone was playing with them (including me). Me and most have settled on one tool (git). And actually this was not my preferred tool of choice, I like Bazaar, but 2 things happened: 1) Bazaar has not won the popular vote (so chances are on a new team I would have to learn git anyway) and 2) DVCS as a technology has stopped being new and exciting. For example at some point OO features and garbage collection was exciting and new. Now they are just another tool in the shed available for use and as I said, this area of tech for me has lost the "wow" factor. I also realized I have a limited bandwidth both to learn and to remember things. I would rather devote this bandwidth to learn new languages or other technologies (databases) rather then learn more DVC systems.
    - loup-vaillant 14y ago
      If you're looking for another "wow" factor in programming languages, the following links may interest you: http://www.tinlizzie.org/ometa/ http://www.tinlizzie.org/ometa/ http://piumarta.com/software/maru/ http://piumarta.com/software/maru/ http://vpri.org/html/work/ifnct.htm http://vpri.org/html/work/ifnct.htm and of course http://www.vpri.org/pdf/tr2011004_steps11.pdf http://www.vpri.org/pdf/tr2011004_steps11.pdf Their way of doing things seems to require a 1000 times less code than current mainstream techniques. They can do a whole language stack in less than 2000 lines of self-implementing code for instance (not super-optimized, but fast enough). Compare with GCC or GHC. Even Lua is bigger.
      - rdtsc 14y ago
        Thank you! Maru and Ometa look interesting. Speaking of terseness, reminds me of Prolog. I remember thinking how beautiful the solutions are but how broken my brain is as I couldn't come up with them on my own. I could see the final result that someone else produced and understand it, but struggle for hours and hours myself. I think at some point levels of meta and abstractions can go that high that only very few smart individuals can effectively create products, others more or less hit a wall.
- guelo 14y ago
  For a team that will be using the tool everyday for years the learning curve isn't that important. Any new hire has a lot to learn when joining any team and scm is just a small part. Even if a team uses git and a new hire is a git master she will still have to learn that specific team's infrastructure and process that goes with it, so there's still a learning curve. Unless it's a very early startup it will take most people a month or two to get really ramped up in a new team and that is plenty of time to learn an scm. Maybe for open source projects it makes sense to stick with the most popular tool but for private teams if you can see an advantage to another tool and it looks like it will be around for a while then there is no reason not to use it.
  - rdtsc 14y ago
    But it can get worse, if a developer is a member of 3 teams. Let's say they have their main job, and 2 open source projects, and somehow all those teams ended up with darcs, hg and git respectively. Now that developer has to learn 3 different set of commands that do largely the same thing. At some point, at least for me, there is a limited working set of memory for things like this. I can keep a couple of language API, keywords, linux shell commands and some git commands. That working set lets me get work done. If I had to add another set of items to this working memory I would rather add another language or more useful linux commands rather than another VC tool.
- beagle3 14y ago
  In case you are not aware (it isn't clear from your post), darcs is among the oldest of the DVCS, making an appearance in 2003 - it predates git, hg, bzr (bazaar v2) and fossil. It came along after arch and baz (bazaar v1), and more or less together with monotone (which was a source of inspiration for git). For a long time, darcs didn't have much of a developer community, possibly due to the choice of implementation language (Haskell). It also had a corner case that could cause a merge to take several days to complete (I suppose they solved it by now; it was rare, but if you hit it, you couldn't really keep using darcs).
sirclueless 14y ago
I like to think of Darcs as the PostgreSQL of distributed version control. They both have correctness as their first priority, sacrificing a little performance as necessary. PostgreSQL was very slow at first but it is closing that gap, and I think the end result is better for it. Git and Mercurial sacrifice correctness in favor of pragmatism in some cases, by taking shortcuts such as three-way merges. Unlike in the relational database world, there is no accepted standard for interfacing with a versioned repository. It remains to be seen whether Darcs, like PostgreSQL, will eventually gather enough steam to build a substantial user base.
- tonfa 14y ago
  I always thought the correctness aspect of Darcs was very weak, from what I remember most of the original "patch theory" wasn't sound
  - sanxiyn 14y ago
    Yes, the original theory was weak and not sound, but they worked on it. There is some initial work towards Coq formalization. http://wiki.darcs.net/Theory http://wiki.darcs.net/Theory
- papsosouid 14y ago
  The problem with that analogy is that you are comparing darcs to a myth. Postgresql was not "very slow at first". It has certainly gotten faster, but it was faster than mysql for real workloads ~15 years ago. It isn't closing a gap, it is pulling further and further ahead. Mysql is only fast if you are using myisam tables and doing a single threaded microbenchmark of repeating a single simple query in a loop. On real benchmarks where there's many connections executing many different queries at the same time, postgresql has always been way ahead of mysql.
lucisferre 14y ago
For those interested Linus' comments on Darcs from 2007 http://markmail.org/message/vk3gf7ap5auxcxnb http://markmail.org/message/vk3gf7ap5auxcxnb
- riffraff 14y ago
  notice that in this message linus says "And in that sense, I do think the two approaches can _complement_ each other" And simmetrically, a few years later, david roundy (the original author of darcs) started working on iolaus[1] which is in fact a darcs-ish implementation on top of git. [1] https://github.com/droundy/iolaus https://github.com/droundy/iolaus now abandoned I believe
- kowey 14y ago
  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.
aeontech 14y ago
I used darcs for all personal repositories for a couple of years. It has a great UI, but I ended up moving to git for two reasons - a) most projects I was working on with other people were using git, and b) there was nothing like github for darcs (and still isn't as far as I know). It was really nice while it lasted though.
- Su-Shee 14y ago
  You might want to take a look at https://patch-tag.com/ https://patch-tag.com/
  - middus 14y ago
    SSL errors on me due to an expired certificate. Great way to build confidence.
- atechie 14y ago
  Darcs is good for personal use, but I moved away primarily because of the exponential merge problem. I think darcs2 takes care of it in most of the cases but NOT always. That is a big question mark for production repository. Darcs is easy to get started with though - to anybody interested I recommend this link - http://blog.interlinked.org/tutorials/darcs.html http://blog.interlinked.org/tutorials/darcs.html . On the other hand if you want to move from darcs to git , use the following - https://github.com/purcell/darcs-to-git https://github.com/purcell/darcs-to-git
  - kowey 14y ago
    I'll just add that these days, people should consider using the Darcs bridge instead: http://wiki.darcs.net/DarcsBridgeUsage 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.
- vito 14y ago
  There's also http://darcsden.com/ http://darcsden.com/ - a little side-project of mine.
cdaven 14y ago
"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.
- sunkencity 14y ago
  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.
- jwr 14y ago
  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.
  - kowey 14y ago
    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)
    - jwr 14y ago
      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").
haakon 14y ago
How does darcs compare to git these days? I know it used to have some significant performance issues on large repos.
- kowey 14y ago
  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.
klodolph 14y ago
The primary pull of the "patch theory" is that it will allow you to share code more easily between different "patch sets" (branches / forks). The reality of software projects means that you can't automate such a process except in the most trivial cases, and other VCSs handle the trivial cases already. You can imagine that I write a new filesystem for Linux, but I wait two years and the FS interface has changed drastically, the old patch is meaningless. If the patch is sufficiently independent textually, then Darcs lets you reorder it anywhere you see fit, even if you know that doesn't make sense. You have detailed knowledge of the system, Darcs doesn't. By contrast, Git/SVN/Hg folk think about snapshots of development. So it's a different paradigm. But the snapshot paradigm is almost always the most useful paradigm, since every snapshot in history (unless you rebase) is going to be one that was actually vetted by a real programmer. Reordering patches throws away the valued actual snapshots that you were working with in favor of automated reconstructions of what a snapshot might have looked like if you had been programming in that order. Of course, you can always do the same dangerous things with Git and rebasing.
- riffraff 14y ago
  What you can't do with git is pull a set of related patches when you have not created a branch for them. Which is apparently useful, as git has cherry-pick for that, and rebase. Except, cherry pick will only work for "in air" commits, and rebase requires you to review all the commits. darcs will happily pull a set of related commits knowing the relations between them. You may have detailed knowledge of the system so in some cases you may do something better than what darcs does, but that does not mean you should be resolving merges and commit dependencies by hand all of the time. Honestly, I have not used darcs in years, but that is the "right" thing I expect from a VCS, and it has no downsides per se[0]. [0]they may be in darcs implementation, or possibly in the theory, but definitely not in the feature
  - klodolph 14y ago
    Rebase only requires you to review the commits to the same extent that merge does, unless you're doing an interactive rebase. Honestly, I expect the differences between Darcs and Git in terms of rebase / interactive rebase / cherry pick / merge to be a matter of implementation. Both systems are fed the same input, both track enough of it, so both could theoretically provide the same output. (I think Darcs is a little better at it, but every merge should be done with a watchful eye in either system.) But I get the feeling that the patch-centric model is encouraging users to play fast and loose with patch order. If you wantonly reorder patches, you might get a sequence of unusable code bases culminating in the current working version of your software. It's easy to move a patch that uses a feature to a point before the feature is introduced. Basically, the claim that "Darcs automatically groups changes which depend on each other" is one that I can't take seriously. How can it know which changes depend on each other, if (for example) they're in different files? By comparison, I hear from the Git folk advice along the lines of, "Be careful with rebase, because it is a destructive operation". And because Git is snapshot-centric, if the app crashes in testing you can look at the SHA-1 used for the build to check out the exact tree used for the build, even years later, if necessary. No tagging required.
DannoHung 14y ago
Darcs is pretty nifty, but until the atomic patch theory has been verified, I'm happy to stay with git.
- dons 14y ago
  Are you expecting git to be verified soon too?
  - etherealG 14y ago
    git's only "theory" that could potentially be verified is merge resolution. which has been. I think darcs approach is a little different.
    - dons 14y ago
      git has plenty of properties that are supposed to be true. The developers write tests for them. The properties being tested could be proven instead.
  - DannoHung 14y ago
    Nope, but git has overall superior tooling, support, and community acceptance. It is generally a superior choice to non-distributed solutions and in absence of a verification of the patch commutability theory, I don't see a significant advantage to the way Darcs approaches the problem. The tree based approach is a little less flexible, but it's still very good.
markokocic 14y ago
Darcs is not "another", it is "the first distributed" version control system that gained some traction in open source projects. Before git usage exploded, darcs was almost exclusively used by haskel and lisp libraries. What killed darcs, besides performance issues with darcs 1, was "one repo one branch" mode, and tedious way of maintaining long lived forks, which wasn't that convenient as what git provides. However, I'm glad that Darcs is still actively developed and used, since it has very nice theory and model behind it, and it still has some very useful concept which are quite unique for it.
- decode 14y ago
  > Darcs is not "another", it is "the first distributed" version control system that gained some traction in open source projects. Wasn't BitKeeper in use by the Linux kernel for several years before Darcs came out?
  - loup-vaillant 14y ago
    > "that gained some traction in open source projects." Therefore, proprietary tools don't count.
    - deleted 14y ago
      [deleted]
  - smacktoward 14y ago
    It was, but not for "several years." Linus started using BitKeeper on the kernel in 2002 (source: http://lwn.net/Articles/130746/ http://lwn.net/Articles/130746/). The first release of Darcs was in March 2003 (source: http://darcs.net/NEWS http://darcs.net/NEWS).
jgfoot 14y ago
Perhaps darcs' most prominent user base is the guys who work on GHC, the Glasgow Haskell Compiler. They still use it, but have not been completely happy: http://hackage.haskell.org/trac/ghc/wiki/DarcsEvaluation http://hackage.haskell.org/trac/ghc/wiki/DarcsEvaluation
- Chirono 14y ago
  Actually, GHC has been using GIT for about a year now. There was a lot of discussion but darcs has (mostly) been dropped. There are a few libraries that are still darcs-controlled but generally because nobody has got round to migrating them I think...
etherealG 14y ago
A quote from the darcs wiki: This is why darcs currently doesn’t always works so well for keeping a “local branch” of some source. The local deviations are likely to cause exponential conflicts after time. Local deviations must either be isolated in some way (kept in separate files) so they never conflict, or changes from upstream needs to be merged in “by hand” and recorded as local patches that doesn’t conflict with the local changes. Can anyone help me reconcile why I would give darcs a try over git if I can't do local branching?
- loup-vaillant 14y ago
  My guess would be, because you don't need to. First, you can do "local branching" by cloning your repository. On a local filesystem, `darcs get` is fast (uses hard links). And instead of `darcs branch`, you use `cd` (personally, I don't see how `cd` is worse, do you have some pointers about that?). Second, the Darcs way of managing patches gets you "spontaneous branches". http://wiki.darcs.net/SpontaneousBranches http://wiki.darcs.net/SpontaneousBranches The main advantage lies in that you can select the patches you push to other repositories. Say you work on some feature. Suddenly you need to fix a bug. The way to do it is, fix the bug right away then send the relevant patches (easy if you name your patches sensibly). Your unfinished feature simply won't get send (unless of course there's an actual conflict).
  - etherealG 14y ago
    I see your point about local branching, but I do prefer git's approach for simplification on large branch sets. Some of the git repos I work with have upwards of 200 branches, having those in folders to be manually managed would be a little overwhelming.
- kowey 14y ago
  We're giving local branches a good think http://wiki.darcs.net/Ideas/Branches 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.
papsosouid 14y ago
It is weird that all the comments are about patch theory. I use darcs because it is by far the easiest, simplest to use DVCS. I don't know anything about patch theory, and I don't care about it at all. I just know I can have a DVCS noob using darcs effectively in a couple minutes, and it will merge properly.
CountSessine 14y ago
I had the pleasure of using Darcs in an open source project some time ago. Can a long-time Darcs user explain to me what I was doing wrong? The build for the project had passed on most platforms, but on one platform in particular (the one I was interested in), the build agent started failing on a particular day a month before. Being able to determine which commit a build started failing at has a great deal of real engineering value, but I couldn't figure out a way to do that with Darcs. The patches are ordered in the repository according to Darcs' own preference, and they're dated according to when they were committed locally, not when they were pushed. I discussed this point with someone else and they said, to paraphrase, "usually, I know which of my patches has caused a problem, so this is a non-issue." It wasn't a non-issue in this case, of course, because I didn't know which of his patches had caused the issue, and no one else had cared to figure out why this third-tier platform wasn't building. Is there any way at all to characterize what exactly a build machine is building at a particular time with Darcs? With perforce and subversion, there's a commit number. Git has a commit SHA hash. What can you do in a build agent to log exactly what is and isn't being built with Darcs?
- kowey 14y ago
  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 http://wiki.darcs.net/Ideas/ShortSecureId) for some thinking about the problem.
kowey 14y ago
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.
- smichael 14y ago
  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) Here's the darcsstat script that reports these numbers: https://gist.github.com/2653180 https://gist.github.com/2653180

92 points by alagu 14y ago

rdtsc 14y ago

The Cambrian Explosion of the distributed version control system has passed I think. Git seems to come out ahead. I think it would be easier to just switch to it. I like Bazaar and used Hg, but this is tool used to collaborate with others (unlike say an editor) so picking a tool that others know and use is important in a team. Darcs has an interesting approach, sure, but that is not enough for it to win mind-share, and I wouldn't spend time looking at bit because I will have a very hard time getting others to do the same. Also the excitement and euphoria about learning and experimenting with distributed VCs is passed. I feel, for most they have stopped having the "wow" factor and became just a tool in the same category as patch, diff, less and tar.

tav 14y ago
It's a sad day, the day a hacker refuses to look at something because they'd "have a very hard time getting others to do the same". By that same token we should avoid looking at the likes of Haskell, Erlang, Rust, etc. You are absolutely right that Git has come out on top, but Darcs definitely merits a look at least. For what it's worth, I was in the Monotone [1] camp against Darcs back in the day... :) [1] http://en.wikipedia.org/wiki/Monotone_(software) http://en.wikipedia.org/wiki/Monotone_(software)
- skrebbel 14y ago
  This. Surely git "has won", but you'd be fitted with a pretty bad sense of history if you think that this is forever. Thus, it definitely does not hurt to keep Darcs in view. I bet that if any version control system is going to replace git, it'll look at least as much like Darcs as anything else. I'm no expert by a long shot, but to me it appears that if we're going to try to finally make version control user-friendly, something inspired by Darcs' patch algebra may well be at the base of it. While Darcs is impractical for a whole set of use cases, it's very practical for a whole other set of use cases.
  - qznc 14y ago
    It will be very hard for Darcs (and Bazaar, Monotone, etc.) to get so much better than git that switching is worth it. Just a better theoretical base for some edge cases is not enough. Hg has also quite some mindshare. I consider it the only DVCS, which still seriously competes with Git. Apart from that, there are niche groups: Haskell with Darcs, Ubuntu with Bazaar.
    - skrebbel 14y ago
      > Just a better theoretical base for some edge cases is not enough. That's why I said "user friendliness". Even on a superficial level, Git is enormously lacking in this aspect. More fundamentally, the way moving changes around between branches works in Darcs is significantly simpler and "hey, it read my mind!" than in Git, where you need to understand the underlying object model and the tools very well to do this well. Sure, many other things are a disaster in Darcs, but I'm not saying Darcs will replace Git. I'm saying something inspired by it well.
    - durin42 14y ago
      > It will be very hard for Darcs (and Bazaar, Monotone, etc.) to get so much better than git that switching is worth it. People said this about Subversion not so long ago.
    - SkyMarshal 14y ago
      Fwiw he didn't say Darcs will replace git, he said that whatever eventually replaces git will likely implement some of Darcs best features like the patch algebra. Hence, it's worth taking a little time to actually understand those features, even if you never use darcs. Plus the mental exercise and learning something new is valuable in and of itself.
- davidw 14y ago
  It's just being cognizant that VC software has positive network externalities. If you want to play with stuff, sure, go ahead, but if vc systems are just part of your toolset, then git has probably won. I'm in the latter camp: I want something solid and dependable - I'd rather spend my experimentation time with a new programming language or something else.
- rdtsc 14y ago
  > By that same token we should avoid looking at the likes of Haskell, Erlang, Rust, etc I think it is good to periodically evaluate the tools used. And initially there was quite a bit of excitement around DVCS and everyone was playing with them (including me). Me and most have settled on one tool (git). And actually this was not my preferred tool of choice, I like Bazaar, but 2 things happened: 1) Bazaar has not won the popular vote (so chances are on a new team I would have to learn git anyway) and 2) DVCS as a technology has stopped being new and exciting. For example at some point OO features and garbage collection was exciting and new. Now they are just another tool in the shed available for use and as I said, this area of tech for me has lost the "wow" factor. I also realized I have a limited bandwidth both to learn and to remember things. I would rather devote this bandwidth to learn new languages or other technologies (databases) rather then learn more DVC systems.
  - loup-vaillant 14y ago
    If you're looking for another "wow" factor in programming languages, the following links may interest you: http://www.tinlizzie.org/ometa/ http://www.tinlizzie.org/ometa/ http://piumarta.com/software/maru/ http://piumarta.com/software/maru/ http://vpri.org/html/work/ifnct.htm http://vpri.org/html/work/ifnct.htm and of course http://www.vpri.org/pdf/tr2011004_steps11.pdf http://www.vpri.org/pdf/tr2011004_steps11.pdf Their way of doing things seems to require a 1000 times less code than current mainstream techniques. They can do a whole language stack in less than 2000 lines of self-implementing code for instance (not super-optimized, but fast enough). Compare with GCC or GHC. Even Lua is bigger.
    - rdtsc 14y ago
      Thank you! Maru and Ometa look interesting. Speaking of terseness, reminds me of Prolog. I remember thinking how beautiful the solutions are but how broken my brain is as I couldn't come up with them on my own. I could see the final result that someone else produced and understand it, but struggle for hours and hours myself. I think at some point levels of meta and abstractions can go that high that only very few smart individuals can effectively create products, others more or less hit a wall.
guelo 14y ago
For a team that will be using the tool everyday for years the learning curve isn't that important. Any new hire has a lot to learn when joining any team and scm is just a small part. Even if a team uses git and a new hire is a git master she will still have to learn that specific team's infrastructure and process that goes with it, so there's still a learning curve. Unless it's a very early startup it will take most people a month or two to get really ramped up in a new team and that is plenty of time to learn an scm. Maybe for open source projects it makes sense to stick with the most popular tool but for private teams if you can see an advantage to another tool and it looks like it will be around for a while then there is no reason not to use it.
- rdtsc 14y ago
  But it can get worse, if a developer is a member of 3 teams. Let's say they have their main job, and 2 open source projects, and somehow all those teams ended up with darcs, hg and git respectively. Now that developer has to learn 3 different set of commands that do largely the same thing. At some point, at least for me, there is a limited working set of memory for things like this. I can keep a couple of language API, keywords, linux shell commands and some git commands. That working set lets me get work done. If I had to add another set of items to this working memory I would rather add another language or more useful linux commands rather than another VC tool.
beagle3 14y ago
In case you are not aware (it isn't clear from your post), darcs is among the oldest of the DVCS, making an appearance in 2003 - it predates git, hg, bzr (bazaar v2) and fossil. It came along after arch and baz (bazaar v1), and more or less together with monotone (which was a source of inspiration for git). For a long time, darcs didn't have much of a developer community, possibly due to the choice of implementation language (Haskell). It also had a corner case that could cause a merge to take several days to complete (I suppose they solved it by now; it was rare, but if you hit it, you couldn't really keep using darcs).

sirclueless 14y ago

I like to think of Darcs as the PostgreSQL of distributed version control. They both have correctness as their first priority, sacrificing a little performance as necessary. PostgreSQL was very slow at first but it is closing that gap, and I think the end result is better for it. Git and Mercurial sacrifice correctness in favor of pragmatism in some cases, by taking shortcuts such as three-way merges. Unlike in the relational database world, there is no accepted standard for interfacing with a versioned repository. It remains to be seen whether Darcs, like PostgreSQL, will eventually gather enough steam to build a substantial user base.

tonfa 14y ago
I always thought the correctness aspect of Darcs was very weak, from what I remember most of the original "patch theory" wasn't sound
- sanxiyn 14y ago
  Yes, the original theory was weak and not sound, but they worked on it. There is some initial work towards Coq formalization. http://wiki.darcs.net/Theory http://wiki.darcs.net/Theory
papsosouid 14y ago
The problem with that analogy is that you are comparing darcs to a myth. Postgresql was not "very slow at first". It has certainly gotten faster, but it was faster than mysql for real workloads ~15 years ago. It isn't closing a gap, it is pulling further and further ahead. Mysql is only fast if you are using myisam tables and doing a single threaded microbenchmark of repeating a single simple query in a loop. On real benchmarks where there's many connections executing many different queries at the same time, postgresql has always been way ahead of mysql.

lucisferre 14y ago

For those interested Linus' comments on Darcs from 2007 http://markmail.org/message/vk3gf7ap5auxcxnb http://markmail.org/message/vk3gf7ap5auxcxnb

riffraff 14y ago
notice that in this message linus says "And in that sense, I do think the two approaches can _complement_ each other" And simmetrically, a few years later, david roundy (the original author of darcs) started working on iolaus[1] which is in fact a darcs-ish implementation on top of git. [1] https://github.com/droundy/iolaus https://github.com/droundy/iolaus now abandoned I believe
kowey 14y ago
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.

aeontech 14y ago

I used darcs for all personal repositories for a couple of years. It has a great UI, but I ended up moving to git for two reasons - a) most projects I was working on with other people were using git, and b) there was nothing like github for darcs (and still isn't as far as I know). It was really nice while it lasted though.

Su-Shee 14y ago
You might want to take a look at https://patch-tag.com/ https://patch-tag.com/
- middus 14y ago
  SSL errors on me due to an expired certificate. Great way to build confidence.
atechie 14y ago
Darcs is good for personal use, but I moved away primarily because of the exponential merge problem. I think darcs2 takes care of it in most of the cases but NOT always. That is a big question mark for production repository. Darcs is easy to get started with though - to anybody interested I recommend this link - http://blog.interlinked.org/tutorials/darcs.html http://blog.interlinked.org/tutorials/darcs.html . On the other hand if you want to move from darcs to git , use the following - https://github.com/purcell/darcs-to-git https://github.com/purcell/darcs-to-git
- kowey 14y ago
  I'll just add that these days, people should consider using the Darcs bridge instead: http://wiki.darcs.net/DarcsBridgeUsage 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.
vito 14y ago
There's also http://darcsden.com/ http://darcsden.com/ - a little side-project of mine.

cdaven 14y ago

"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.

sunkencity 14y ago
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.
jwr 14y ago
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.
- kowey 14y ago
  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)
  - jwr 14y ago
    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").

haakon 14y ago

How does darcs compare to git these days? I know it used to have some significant performance issues on large repos.

kowey 14y ago
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.

klodolph 14y ago

The primary pull of the "patch theory" is that it will allow you to share code more easily between different "patch sets" (branches / forks). The reality of software projects means that you can't automate such a process except in the most trivial cases, and other VCSs handle the trivial cases already. You can imagine that I write a new filesystem for Linux, but I wait two years and the FS interface has changed drastically, the old patch is meaningless. If the patch is sufficiently independent textually, then Darcs lets you reorder it anywhere you see fit, even if you know that doesn't make sense. You have detailed knowledge of the system, Darcs doesn't. By contrast, Git/SVN/Hg folk think about snapshots of development. So it's a different paradigm. But the snapshot paradigm is almost always the most useful paradigm, since every snapshot in history (unless you rebase) is going to be one that was actually vetted by a real programmer. Reordering patches throws away the valued actual snapshots that you were working with in favor of automated reconstructions of what a snapshot might have looked like if you had been programming in that order. Of course, you can always do the same dangerous things with Git and rebasing.

riffraff 14y ago
What you can't do with git is pull a set of related patches when you have not created a branch for them. Which is apparently useful, as git has cherry-pick for that, and rebase. Except, cherry pick will only work for "in air" commits, and rebase requires you to review all the commits. darcs will happily pull a set of related commits knowing the relations between them. You may have detailed knowledge of the system so in some cases you may do something better than what darcs does, but that does not mean you should be resolving merges and commit dependencies by hand all of the time. Honestly, I have not used darcs in years, but that is the "right" thing I expect from a VCS, and it has no downsides per se[0]. [0]they may be in darcs implementation, or possibly in the theory, but definitely not in the feature
- klodolph 14y ago
  Rebase only requires you to review the commits to the same extent that merge does, unless you're doing an interactive rebase. Honestly, I expect the differences between Darcs and Git in terms of rebase / interactive rebase / cherry pick / merge to be a matter of implementation. Both systems are fed the same input, both track enough of it, so both could theoretically provide the same output. (I think Darcs is a little better at it, but every merge should be done with a watchful eye in either system.) But I get the feeling that the patch-centric model is encouraging users to play fast and loose with patch order. If you wantonly reorder patches, you might get a sequence of unusable code bases culminating in the current working version of your software. It's easy to move a patch that uses a feature to a point before the feature is introduced. Basically, the claim that "Darcs automatically groups changes which depend on each other" is one that I can't take seriously. How can it know which changes depend on each other, if (for example) they're in different files? By comparison, I hear from the Git folk advice along the lines of, "Be careful with rebase, because it is a destructive operation". And because Git is snapshot-centric, if the app crashes in testing you can look at the SHA-1 used for the build to check out the exact tree used for the build, even years later, if necessary. No tagging required.

DannoHung 14y ago

Darcs is pretty nifty, but until the atomic patch theory has been verified, I'm happy to stay with git.

dons 14y ago
Are you expecting git to be verified soon too?
- etherealG 14y ago
  git's only "theory" that could potentially be verified is merge resolution. which has been. I think darcs approach is a little different.
  - dons 14y ago
    git has plenty of properties that are supposed to be true. The developers write tests for them. The properties being tested could be proven instead.
- DannoHung 14y ago
  Nope, but git has overall superior tooling, support, and community acceptance. It is generally a superior choice to non-distributed solutions and in absence of a verification of the patch commutability theory, I don't see a significant advantage to the way Darcs approaches the problem. The tree based approach is a little less flexible, but it's still very good.

markokocic 14y ago

Darcs is not "another", it is "the first distributed" version control system that gained some traction in open source projects. Before git usage exploded, darcs was almost exclusively used by haskel and lisp libraries. What killed darcs, besides performance issues with darcs 1, was "one repo one branch" mode, and tedious way of maintaining long lived forks, which wasn't that convenient as what git provides. However, I'm glad that Darcs is still actively developed and used, since it has very nice theory and model behind it, and it still has some very useful concept which are quite unique for it.

decode 14y ago
> Darcs is not "another", it is "the first distributed" version control system that gained some traction in open source projects. Wasn't BitKeeper in use by the Linux kernel for several years before Darcs came out?
- loup-vaillant 14y ago
  > "that gained some traction in open source projects." Therefore, proprietary tools don't count.
  - deleted 14y ago
    [deleted]
- smacktoward 14y ago
  It was, but not for "several years." Linus started using BitKeeper on the kernel in 2002 (source: http://lwn.net/Articles/130746/ http://lwn.net/Articles/130746/). The first release of Darcs was in March 2003 (source: http://darcs.net/NEWS http://darcs.net/NEWS).

jgfoot 14y ago

Perhaps darcs' most prominent user base is the guys who work on GHC, the Glasgow Haskell Compiler. They still use it, but have not been completely happy: http://hackage.haskell.org/trac/ghc/wiki/DarcsEvaluation http://hackage.haskell.org/trac/ghc/wiki/DarcsEvaluation

Chirono 14y ago
Actually, GHC has been using GIT for about a year now. There was a lot of discussion but darcs has (mostly) been dropped. There are a few libraries that are still darcs-controlled but generally because nobody has got round to migrating them I think...

etherealG 14y ago

A quote from the darcs wiki: This is why darcs currently doesn’t always works so well for keeping a “local branch” of some source. The local deviations are likely to cause exponential conflicts after time. Local deviations must either be isolated in some way (kept in separate files) so they never conflict, or changes from upstream needs to be merged in “by hand” and recorded as local patches that doesn’t conflict with the local changes. Can anyone help me reconcile why I would give darcs a try over git if I can't do local branching?

loup-vaillant 14y ago
My guess would be, because you don't need to. First, you can do "local branching" by cloning your repository. On a local filesystem, `darcs get` is fast (uses hard links). And instead of `darcs branch`, you use `cd` (personally, I don't see how `cd` is worse, do you have some pointers about that?). Second, the Darcs way of managing patches gets you "spontaneous branches". http://wiki.darcs.net/SpontaneousBranches http://wiki.darcs.net/SpontaneousBranches The main advantage lies in that you can select the patches you push to other repositories. Say you work on some feature. Suddenly you need to fix a bug. The way to do it is, fix the bug right away then send the relevant patches (easy if you name your patches sensibly). Your unfinished feature simply won't get send (unless of course there's an actual conflict).
- etherealG 14y ago
  I see your point about local branching, but I do prefer git's approach for simplification on large branch sets. Some of the git repos I work with have upwards of 200 branches, having those in folders to be manually managed would be a little overwhelming.
kowey 14y ago
We're giving local branches a good think http://wiki.darcs.net/Ideas/Branches 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.

papsosouid 14y ago

It is weird that all the comments are about patch theory. I use darcs because it is by far the easiest, simplest to use DVCS. I don't know anything about patch theory, and I don't care about it at all. I just know I can have a DVCS noob using darcs effectively in a couple minutes, and it will merge properly.

CountSessine 14y ago

I had the pleasure of using Darcs in an open source project some time ago. Can a long-time Darcs user explain to me what I was doing wrong? The build for the project had passed on most platforms, but on one platform in particular (the one I was interested in), the build agent started failing on a particular day a month before. Being able to determine which commit a build started failing at has a great deal of real engineering value, but I couldn't figure out a way to do that with Darcs. The patches are ordered in the repository according to Darcs' own preference, and they're dated according to when they were committed locally, not when they were pushed. I discussed this point with someone else and they said, to paraphrase, "usually, I know which of my patches has caused a problem, so this is a non-issue." It wasn't a non-issue in this case, of course, because I didn't know which of his patches had caused the issue, and no one else had cared to figure out why this third-tier platform wasn't building. Is there any way at all to characterize what exactly a build machine is building at a particular time with Darcs? With perforce and subversion, there's a commit number. Git has a commit SHA hash. What can you do in a build agent to log exactly what is and isn't being built with Darcs?

kowey 14y ago
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 http://wiki.darcs.net/Ideas/ShortSecureId) for some thinking about the problem.

kowey 14y ago

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.

smichael 14y ago
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) Here's the darcsstat script that reports these numbers: https://gist.github.com/2653180 https://gist.github.com/2653180