[darcs-users] Re: current status of darcs

John Goerzen jgoerzen at complete.org
Fri Mar 9 20:32:00 UTC 2007


On 2007-03-09, David Roundy <droundy at darcs.net> 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




More information about the darcs-users mailing list