Generally very nice. Replying to darcs-users to get others' take, [email protected] writes:
> +- **Human Friendly** - Most VCSs impose a historical orer on changes. But > humans > +don't work like that. We don't think of two different changes that implement > +different features as having a particular order. Well, neither does Darcs. > In > +Darcs, you give a name to each patch (e.g. 'feature X') and you tell Darcs > which > +set of patches you want (e.g. "I'd like feature Y and Z but not X"). Darcs > will > +know what to do with this. This makes some "complicated" mergers not > complicated > +at all in Darcs. Sell a little: s/some/many/ in the last sentence.<wink> > +- **Smart** - Darcs understands dependencies between patches. You can't > delete > +a file before you add it. You can't rename a function before you write it. > The This isn't true. It's quite possible to write top-down, invoking an as yet undefined function. Reviewing the high-level function, you decide the subroutine's name is poor, and change it. Then you write the function. I think you're referring to the token-replace patch type, but the rules for that are too subtle to try to explain on this page. At least for me.<wink> > +rules Darcs uses are simple but powerful. Darcs understands when two patches > +can be reordered and when they can't. Darcs uses dependencies to know when > there > +is a conflict (e.g. Bob can't rename file foo.txt to bar.txt if Alice > already > +renamed it to something else). This means that when Darcs finds a conflict, > it > +is likely to be a genuine conflict that requires a human to resolve (Alice > and > +Bob must settle on a name for the file). Something says "this needs work" to me. Specifically, you mention "conflict" "too many" times, and do not focus enough on how Darcs normally makes things go smoothly. (I don't have an immediate suggestion for improvement, I just want to remark that I think it probably can be improved, and I think it would be helpful to do it.) > +You don't need to know Patch Theory to use Darcs. As a user, everything you > +need to know is in the [Patch Reordering](../Patch Reordering) page. That > said, Do users really need to know about patch reordering? The only thing that would be useful to new users is quite high level: knowing that "darcs pull A; darcs pull B" has exactly the same semantics as "darcs pull B; darcs pull A". But that's not patch reordering, that's "pull reordering". Ie, the advantage to the user is "Darcs knows how to reorder patches, so you can forget about non-commutativity of VCS operations; trying things in a different order won't help, so you don't need to think about it." Or am I missing something? > +if you are keen to know more about the theory behind Darcs, we are more than > +happy to tell you all about it. > hunk ./Patch\32\Theory/Index.page 8 URLs to the patch theory appendix and/or (maybe better) the mailing list? Or would that be too cluttered? > +1) Alice creates a new repository which creates a new file called Foo.txt > hunk ./Patch\32\Reordering.page 158 > +2) Bob pulls from Alice and he renames Foo.txt to Bar.txt > hunk ./Patch\32\Reordering.page 160 [...] > +As you can see, there is a mismatch between how the traditional VCS thinks > +about your work and how you think aobut our work. In contrast, Darcs thinks s/aobut our/about your/ > +the way you do. You think in terms of "I want feature X" and so does Darcs. Very well put. Some people may disagree (at least when constrained to work in their formal processes), but those folks are unlikely to love Darcs no matter what we do. _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
