[darcs-users] Fwd: Darcs Problems

[Stephen J. Turnbull]

John Lato writes:

 > Put simply, git manages branches for you.  With darcs, you have to manage
 > them yourself.

That is it, in a nutshell.

However, I think there are some aspects of daggy branches that don't
fit will with Darcs:

 > Next, suppose Bob asks Alice to review branch "bar". [...]
 > and now, Alice can see not only the commits in "bar", but exactly where
 > they are in the graph in relation to other branches.  So she might see
 > 
 > * hash (HEAD, bar) add bar-features
 > * hash whitespace only
 > * hash (stable-v.1.0) some stable commit
 > * hash Merge branch old-cool-feature into stable-v.1.0
 > 
 > So she knows not only what Bob added to bar, but also that his code was
 > based on the stable-v.1.0 branch, and exactly where Bob's work starts.  Now
 > Alice has much better knowledge of the context of the bar code.
 > 
 > With darcs, that sort of information isn't as readily available.

True, but I don't think this DAG-based analysis makes sense in Darcs.
git branches are based on history, where history is a partially
ordered set of versions.  A branch, of course, is totally ordered.

It seems to me that, unlike the explicit history in a DAG-oriented
VCS, in a patch-oriented VCS with good support for cherrypicking,
history is implicit in the subset (of patches) relationship.  Because
of cherrypicking, history is going to be more or less fuzzy.  The
granularity of versions will also be much coarser than in git.
Because of commutation, I don't think it makes sense to think of every
subset of patches as a version, any more than every set of blobs is a
tree in git.

If I were going to try to implement this (unfortunately I don't speak
Haskell and don't have time to learn that and the large body of code
that is Darcs, too), that's how I'd design it.  Versions are subsets
of the universe of known patches, branches are sequences of versions.
In principle I lean toward the sequence being implicit in the subset
relationship, but in practice I expect that there will be an explicit
log of versions (like the DAG of git commits).

 > Probably the closest is "darcs changes --from-tag=.*", but if bar
 > is based on a feature branch that's under active development it may
 > not have recent tags.  In that case, it's not clear that bar is
 > based on that feature-branch at all;

Indeed, I find it surprising that Darcs has no equivalent to "bzr
missing" or "hg incoming/outgoing".  (git rev-list would be overkill
for Darcs!)