zooko wrote: > On Jan 24, 2009, at 8:41 AM, Tommy Pettersson wrote: > >> Darcs (and SVK) are "not recommended", because the alternatives can >> all handle large repos, whereas darcs can not > > Sounds like a reasonable recommendation. I would be interested in > having some automated generation of graphs of darcs performance and > scalability, generated by the buildbot.
I think Darcs 2 has come a long way towards support for large repos and with more and smarter benchmarks and graphs should be on its way to fixing whats left and then proving to everyone else that it can handle the large repos. >> The article also describes darcs' repo-is-a-branch-is-a-repo as >> inflexible compared to the competitors. This puzzles me, because I >> find this freedom *extremely* flexible. But I have not used any of >> the other systems, so I don't know what I'm missing out on. > > Yes, this is a common criticism of darcs. I can't tell whether there > is really some advantage to the way other dvcs's have separate > notions of branches and of repos, or whether the users of those > systems are mistakenly thinking that darcs's branch==repo causes some > problems that it doesn't. So I've used both hg and git a small bit at this point and I've seen the "gee whiz branches" stuff and I don't quite get it, either and generally use cloning rather than branch management. Most of the demonstrations I've seen where someone lauds branch management it generally seems that darcs cherry picking is superior. Some talk about how "quick" branches can be swapped, but a local darcs get (or a remote darcs get with a very primed cache) in my experience is often close enough in speed. Then there are the masochists that prefer to work in only one working directory while working on several features for multiple branches, switching back and forth, and as far as I know most of those were trained that way by old school RCS/CVS and can't break the cycle of torture. Theoretically such a person could get by with lots of darcs --pull/--obliterate pairs. The only remaining argument is space efficiency and on the server side that will be helped once --no-working-tree is finished and if you are worried about working tree space on a desktop/laptop then you probably have other problems to worry about... But then I don't personally deal with any 20 GB+ working trees and I don't see why someone sane would... (I could see having GBs of history, though...) -- --Max Battcher-- http://worldmaker.net _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
