Guillaume Hoffmann writes: > People want something that *works*. That's all.
Well, actually they want something that does "things they need done," and *works in that application*. This is something I don't see in http://darcs.net, or in http://darcs.daniel.carrera.bz/. I think the section heads "Distributed", "Interactive", "Smart", "Going Places" do appeal to those user needs. Unfortunately, the only one that really delivers is "Interactive". "Distributed." What's interesting about this is not the client vs. server distinction, or "full command sets" (what, no dumbed-down version that does nothing useful? is this going to be one of those things that you need to remember all the commands and it takes years to become a power user?) Rather, "Anywhere you work, Darcs records your work. On the train. In the plane. At the zoo. In Timbuktu.[1] It stays out of your way, but it knows all about your project, and you can ask it what you did yesterday, or how Janice's most recent version differs from yours. Even if she's in Tucumcari---and you're not. And when you get home, Darcs helps you sort and organize your new ideas, then helps you integrate them with your main line of development. And your work is yours, the group's is the group's. Darcs keeps both sorted, without putting up any unnecessary barriers between you and your colleagues when you *want* to share." "Interactive." The current blurb is good, but links forward and back to "Distributed" and "Smart" would be useful. A little more explanation would help. For example, "With Darcs you don't need to remember a sheaf of options for twiddling your workflow. If it's obvious what needs to be done, Darcs just does it. If it's not, Darcs will ask you what you mean. Darcs will record all your new work in go, if you like, or it will help you sort out groups of *related* changes, and record each group separately. For example, you can even split changes within a single file into an 'experimental feature' and a raft of 'typo fixes', and send the latter out separately to everyone in your project, while reserving the experimental work until you're done with it." "Smart." Pretty weak. What does this intelligence mean to you? Well, mostly it's about Darcs staying out of your way. I'm not really sure what to say about it, but something that should go in there is "You should be nervous when you let your computer merge independently developed features into one line of development. You might as well just 'shuffle the deck', for all the judgment that your PC has. But Darcs is based on a 'theory of patches' that allows it to compute when a merge is safe, and when it isn't. And it plans its own strategies for merging, so you don't have to think about it. Except when you and Janice have drafted different changes to the same function---and then you *do* have to think about it, don't you? Darcs is smart enough to stay out of your face when it can, and to let you know that here's a problem that requires your 'executive decision' when it can't." The above is all way verbose (go ahead, try and fit it in the current space! it won't, not at fontsizes > 5px :-). But maybe there are some ideas or even actual phrases to pick up. > > The point I was trying to convey with those bits is that > > > > - we're using mathematics! Which automatically makes us better than > > the competition, because > > > > - they are just doing whatever seems like a good idea at the > > time. That's not very appealing logic. And it's actually not true. Most of the power of patch theory *in practice* is due to the utterly trivial case where two patches don't affect that same files. Then the commute of the two patches doesn't even change the representation of either. Everybody does that, the operation is called "patch application without conflict". Darcs does it better, but unfortunately I don't think we even have an example of a merge where Darcs succeeds but others don't. > > - though the internals are very clever, you don't have to be very > > clever to use Darcs. > > I agree with you on this, and I think this is the only place where we > should allude to darcs' internals. I'd spin it differently. How clever you need to be to use Darcs is a matter entirely of UI. The important thing about the mathematics/ internals is having confidence that Darcs is not screwing up behind your back. git (even more so than Mercurial and Bazaar) can make a similar claim though, since (until recent versions) it never destroyed history until you told it to do so (and I don't mean "git rebase", which hides but doesn't destroy history, especially with the advent of reflogs; I mean "git prune"). But git doesn't try to be very smart about merging etc. It just does the traditional 3-way merge, and only in the last few months did it even learn not to apply identical patches twice in rebase. "Going Places." Urk. Guillaume puts it very well: > It's honest to say it, but once again, it is hard to formulate this in > a short discourse without having people thinking: > "Hmm so what are they going to break in the next 6 months ?". And then > if you go as far as mentioning darcs' different repository formats, > people are scared. (I do not have empirical proof of this, but this is > quite scary in theory, right ?). Indeed. A brief review of the [email protected] archives will convince you that format proliferation pisses the users off royally. > > While this perception [that git and hg are more mature] is > > widespread, I'm not convinced that it's actually true. I think it is. First, they're both in widespread use for projects that are VC hell-on-wheels: the Linux kernel and X.org. git is infrastructure for enterprise-strength products like Github, while Mercurial is Sun's VCS of choice. I really don't think Darcs is ready for any of those roles. So these products are "mature" in the sense of delivering what they promise (even if they're not as promising as Darcs). > > I wanted to gently challenge that assumption by implying that > > maybe 1) git/hg get attention because they're "new kids on the > > block"; No, they get that attention because they deliver. This is important to understand, not because Darcs should compete on the basis of what those products deliver, but because this whole line of argument is missing the point that Guillaume raises: users want function, not theory, and Darcs is getting less attention than it deserves because its marketing is too reliant on theoretical rather than practical benefits. > What about putting a link to a wiki page "darcs vs other DCVSes" in > the "User Resources" section ? I don't really think this is relevant to most potential new users. Footnotes: [1] Darcs was Dr. Seuss's VCS of choice, it seems. :-) _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
