[darcs-users] Fwd: Darcs Problems

[John Lato]

On Thu, Feb 28, 2013 at 11:14 PM, Stephen J. Turnbull <stephen at xemacs.org>wrote:

> 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.
>

Agreed.  This is a big part of my point, although in much clearer verbiage.
 A clear history is very useful for determining the context of current
work.  Git users value this history quite highly, as evidenced by the vast
amount of time git users spend rebasing to clean up history, developing
best practices for maintaining a clean history, etc.  Patch-oriented VCS's
don't really have anything comparable.

I was thinking about a possible implementation a few days ago, and came up
with this idea.  Darcs could add another special patch, which I'm calling a
base patch.  A base patch would have the following properties:

1.  Every patch applied after a base patch depends on the base patch.
2.  A base patch doesn't depend on anything, but it conflicts anywhere its
dependents would conflict.

This would make a base patch act as essentially a starting point for a
group of patches that logically work together (they're all based on the
base patch).  I think you'd also need either a tag or another special patch
to act as the other end of a base patch.

I think an equivalent statement is that a base patch doesn't commute with
any of its dependents, but it does commute with any antecedent patches its
dependents commute with.

What the base patch gives you is the ability to pick commits without their
dependencies.  Suppose you have two branches, stable and dev, and you want
to pick a patch 'hotfix' from dev to stable.  hotfix will most likely have
several other dependencies in dev, but you don't want those.  You want to
just take hotfix and fix any conflicts.  So you would do the following:
make a new repo 'tmp-dev', which has everything in 'dev' except 'hotfix'
apply a base patch
pull hotfix
from the stable repo, cherrypick tmp-dev's hotfix (which will also bring
the base patch)

When trying to apply the base patch to the stable repo, the base patch will
conflict everywhere hotfix's dependencies are unmet.  To resolve the
conflicts, we first undo hotfix, then apply hotfix' (the new patch).  We
don't actually touch the base patch when resolving conflicts, but after the
resolution, the base patch's dependents have changed, so now it will only
conflict where hotfix' would (since the original hotfix is undone).  At
this point, the developer would apply a tag (or end-base) patch and it's
done.

A lot of this work need not be done explicitly.  For cherrypicking, darcs
could ask the user for each patch whether to pull it or not, and
automatically create an appropriate base patch.

I haven't given too much thought to this, but there's probably substantial
overlap with the darcs-rebase work that's been going on.  I'd appreciate it
if someone who's familiar with that (Ganesh?) could comment on this.  If
it's a good idea, maybe I could try to hack it up, or somebody else might
be inspired to work on it.

John L.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20130301/caa1a850/attachment.html>