Guillaume Hoffmann writes: > Hi Michael, > > > However, it's not clear to me what the benefits of the theory are > > in practical terms. Is anyone able to explain why might one > > prefer this model over those that seem to underly the more > > mainstream systems? > I recently read a Mercurial tutorial (hginit.com). It takes some > time explaining why you need to run "hg merge" so as to rewire the > history right (http://hginit.com/02.html). Of course this has to be > in the tutorial because it's how Mercurial works, and doing "hg > merge" happens all the time in a distributed environment. Git and > Bazaar work similarly. On the other hand, darcs does not have such > a command because it is not needed. > > So the plus of darcs for me is that you need to learn less and type > less in order to achieve the same result than with the > aforementioned systems.
You don't get the same result. Darcs is ahistorical; it's very difficult to recover an accurate history of changes. (Many users of history-DAG-oriented (hDAG) systems claim that knowing the context of a change is an aid in debugging. That's a YMMV kind of thing, of course. Legal departments are also often very interested in such history for some reason.) It's also quite difficult to identify a particular version in Darcs, unless it has been tagged. Finally, it is nearly impossible to have a "fully tested repository" in Darcs, because of the combinatorial explosion of possible versions. (Of course in the hDAG systems cherrypicking allows a similar combinatorial explosion; however, it is reasonable to set up a system in which every published commit in the DAG has been tested.) Whether any of this matters to a particular user is a separate question. If it doesn't matter to you, then lack of need for a merge command may mean Darcs is for you. OTOH, in git I basically never use the merge command. If I want to merge a branch in the same git repo, I use "git pull . other-branch". Same number of keystrokes as "darcs pull other-branch" as a matter of fact. :-) What I've never seen, but would be really interesting to see, is a demonstration of a merge that Darcs with patch theory can do but an hDAG-based system fails at. Bonus points if the solution to the conflict is not obvious to human eyes. Somebody mentioned "semantic patches" earlier. I think it's reasonable to consider file copy/move as a form of semantic patch, as well as something like token-replace. But to extend that to provably correct merging, we need a semantics functor. For example, Makefiles refer to files in the project; this means that any change in the name of a file must be reflected in the Makefile. Worse, suppose that the reason that foo.c is mentioned is that it needs special CFLAGS because of the function bar(). Now foo.c is refactored into foo.c and baz.c; the CFLAGS must follow bar(), but how is the VCS supposed to know that? So I don't really think that the correctness we can prove with current purely textual patch theory is all that interesting from a programming standpoint. The real question is whether in practice it can reduce the number and complexity of conflicts that must be resolved by the user (application programmer). _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
