[darcs-users] Fwd: Darcs Problems

[Stephen J. Turnbull]

John Lato writes:

 > Besides, that's rather beside the point.  git-rebase is cheap because it's
 > very common, and it needs to be cheap to be used widely in order to keep
 > histories clean.  Which was my main point.  Unless you're arguing that
 > because git-rebase  is usually fast, git users just use it arbitrarily
 > without regard to a clean history?

Sorry about introducing the performance red herring here.  What I want
to argue is that rebase allowing you to mandate a linear history (a
better characterization of what you really get from rebase) is
insufficient to keep history clean in the sense of allowing easy
cherry-picking: you also need a well-factored design.

 > >  > 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.
 > >
 > > I take it a base patch must be empty?  Surely it would depend on the
 > > patch that adds the only file the base patch patches, for example? ;-)
 > 
 > I highly doubt that situation would come up much in practice,

I don't understand what you mean.  Every file gets added at some
point.  This means that you can go all the way back to the beginning
of the world unless the patch is empty.

 > and even if it does I think the correct approach would be to give
 > the user a choice between aborting, creating a null file, or
 > attempting to patch a different file.

AFAICS only aborting would make sense in general (you can't apply a
change-line or delete-line diff to a null file, you can't leave the
file null and claim to have applied the diff, and darcs tracks renames
so it should know which different file if there is one).

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

So by "undo" you mean obliterate the patch but leave the changes
(including conflict markers) in place, for convenience of editing?

 > >  > then apply hotfix' (the new patch).  We don't actually touch

What does "actually touch" mean?

 > >  > 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).
 > >
 > > I don't understand why this changes anything.  The dependencies of
 > > hotfix are determined by the patches that establish the context it
 > > needs to be applied to.  I don't see why anything would change for
 > > hotfix' if it contains the same changes are hotfix.
 > 
 > hotfix' is a darcs merge patch, so it's hotfix+manual edits.  The manual
 > edits make the difference :)  Its dependencies would be hotfix, hotfix(-1)
 > (the inverse patch), and whatever else is between it and the base patch
 > that's necessary for context.

IIUC, for these effects your "base patch" could be implemented as a
Darcs tag.

I see two problems with the theory you present though.  One is that
hotfix' is just going to be a new patch.  The other is that AFAIK (see
caveat below) there is a theorem of patch theory that says hotfix'
can't depend on both hotfix and -hotfix, since hotfix + -hotfix = 0.

And I still don't understand how you handle context that was
established outside of the base patch and subsequent patches, unless
the base patch is implemented as a tag (which guarantees that no such
context exists).

 > This workflow would be enabled by the base patch implementation.  What a
 > base patch provides to the user are two features:

I don't want to be harsh, but I suspect this is based on an incomplete
understanding of how patch theory works.  I don't claim to understand
patch theory myself, except that it seems clear that the only way to
create a given patch that no dependency can "leapfrog" is for the
given patch to be a tag, ie, a patch that depends on all "preceding"
patches in the repo and thus defines a version.  Your idea of a base
patch that doesn't depend on anything doesn't seem consistent with the
basic ideas of patch theory.

It occurs to me that Ben's ideas may imply a sort of "tag algebra" to
go with "patch algebra".