On 2007-03-09, David Roundy <[EMAIL PROTECTED]> wrote: > The basic idea is that we're going to have to give up the simplicity of > storing all changes as a linear sequence. We'll have some sort of a tree > of primitive changes, with some branches "cancelled". If there's more than > one branch that hasn't yet been cancelled, you've got a conflict in your > repository. It's not as beautiful as conflictors would be, and doesn't fit > so well with the current code base, but it's intuitively obvious that this > approach describes a solution, and that this solution can be represented in > the existing commutation framework.
I'm not sure that I follow entirely here, but what you're describing sounds a lot like Mercurial, I think. In Mercurial, your tree grows from the ground. Each commit has a parent. One parent can have multiple children; such a situation is a fork/branch. If a patch has 2 parents, it is a merge. Each patch has 1 or 2 parents. The topmost patch in a simple nonbranching tree is the head. When you create a second branch, you now have two heads. Heads represent unmerged changes. When you merge, you reduce the number of heads in the repository by 1. It all is very much like darcs on a certain level, and very much different than darcs on another, and I'm not sure I can quite verbalize that just yet. But darcs essentially has a similar concept, with the difference that it is very unusual to have more than one head in a repo at a given time. That is, in a single repo, you usually merge as soon as there is a conflict (and sometimes a merge doesn't require a commit). I wonder how close you feel what you're proposing is to what Mercurial is doing? http://upload.wikimedia.org/wikipedia/en/a/ac/Hgk.png shows the Mercurial repo viewer which illustrates this, though this is an extremely complex example. -- John _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
