[darcs-users] Re: current status of darcs

[John Goerzen]

On 2007-03-10, David Roundy <droundy at darcs.net> wrote:
> The difference (I believe) is that in darcs the tree representation would
> just be a convenient representation of a set of changes, while the
> mercurial tree itself is the history.  I'm not stating myself very clearly,

Right, that's exactly it.  Mercurial is essentially darcs with each
patch depending on the one recorded immediately before.

> but the difference is that in mercurial, the shape of the tree, and the
> order of the changes in the tree means something.  In darcs, it does not
> (modulo dependency constraints).  This is why darcs supports first-class
> cherry picking and mercurial (so far as I can see) does not.  Similarly, it

You are right that it does not, but via the transplant extension, it
comes *extremely* close.  So close, in fact, that when you later do a
full merge from the branch, it will not attempt to merge patches that
have already been merged.

Actually, depending on your viewpoint, it is a bit better or a bit worse
than darcs.  In my opinion, it's a bit better, because you can
cherrypick a patch even if you don't want the patches it depends upon.

> But the representation, or structure, is indeed very similar.  It's just
> that darcs would only have a branch when there is a conflict, not for
> ordinary merges, and the branch would only involve the primitive changes
> that conflict (e.g. the conflicting lines) rather than the changesets.
> Another difference is that there isn't a unique tree describing a given
> state of the repository in darcs.

Does this still hold with your planned "canceled" branches though?

I guess it may not even hold right now.  Consider two users that check
out repo by tag TAG1.

Each independently commit code, and this code is later pulled into the
repo.  We have two sets of code that depend on TAG1.  Are they two
branches or not?

Well, in Mercurial, they would be, since TAG1 has two children -- even
if a merge can be done fully automatically without conflicts.

In Darcs, well, they *could* be.  If they don't conflict, you could just
pull both sets in and you'd get the same result as you'd have if you had
hg merged something.  But assuming each patch depends on the previous
one, you could just as easily darcs get --to-patch to grab one branch or
the other.  The context information in a darcs patch is very similar to
the parent hash in a mercurial patch, isn't it?

I guess it all boils down to "what is a branch?"  And can one call
something that implicitly exists and is implictly merged a branch?

The Mercurial UI can blur that line, too; hg fetch will automatically
merge in non-conflicting changes just as darcs pull will.  The original
branching is there to see in the history if anyone cares, but it doesn't
have to be in your face too much.

> In fact, the invisibility of (ordinary) merges I consider a *extremely*
> important feature.  It greatly affects how the code scales to large number
> of developers, as an approach like mercurial that records everything
> everyone does generally leads to a number of commits that is O(N^2) in the
> number of active developers in the limit that pulls happen regularly (or
> changes are pushed rarely, but most developers have recorded changes that
> aren't in the central repo, i.e. they are active)--which isn't an unlikely
> limit.

Again, I'm not sure I've followed this, but....  it seems that Mercurial
is optimized for a case where upstream doesn't necessarily apply the
literal patches sent in.  Actually, a lot of hg folks seem to use mq as
well.  But conflict resolution in hg is often automatic and I don't
think it gets in the way like you may think it does.

It is somewhat of a different work model.  In darcs, you expect upstream
to apply the literal patch you send in.  (If they don't, you are merging
anyway.)  Mercurial views a submission to upstream as the start of a
discussion.

It is interesting to see how both Darcs and Mercurial have tools for
reworking the changes in a local repo, but they are quite different from
each other as well.

> In many ways quite different.  Really only similar in that it's a tree or
> dag describing a bunch of changes.  In the case of darcs, the structure
> won't be related to the history, and the changes will be primitive changes,

In my experience, it seems than dependencies often make the structure
related to history anyway, yes?

> so the nodes won't in general be meaningful states (i.e. states that
> anyone's repository was ever in).
>
> Also, I think we'll probably go with a tree rather than a DAG, mostly

Could you expand DAG for me please?

> because the tree seems simpler to deal with.  We could represent the same
> information in a DAG, but we still couldn't avoid duplicate information,
> and it's just more complicated.  Igloo thinks (or thought?) we should go
> with a DAG, but I'm not unconvinced.

Thanks for this interesting discussion.

-- John