[darcs-users] Fwd: Darcs Problems

[Stephen J. Turnbull]

John Lato writes:

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

git rebasing doesn't take that much time if you have a modular design
and a clean history.  If you lack either of those requisites, no VCS
is going to be able to help you much.  Even with the "dissolve to
atomic changes" approach suggested by Ben Franksen, you will lose
semantic dependencies among atomic changes that cause them to recorded
together in a "coherent changeset" (Tom Lord's term).

 > 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? ;-)

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

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.

>>>>> Ben Franksen <benjamin.franksen at bessy.de> writes:

 > I guess what I'd really want here is a new command, some version of
 > "darcs pull", that disregards patch identities (including patch
 > meta-data) and only considers atomic changes (hunks, etc). The idea
 > is to "dissolve" all the <unwanted dependencies>, and pull exactly
 > the set of atomic changes contained in them that are necessary to
 > apply the selected patch (<hotfix>). The result should then be
 > packed into a new patch.

I think that this is much more in line with what is really needed to
resolve spurious dependencies.  However, if the changesets really are
coherent, you'll end up with an incoherent version.

The "new patch" mentioned here should be a new type of patch with
"advisory conflicts" with the actual patches its atomic changes
were drawn from.  Or perhaps such conflicts could be resolved
automatically.  I suspect not: in some cases when you pull the "new
patch", you would want conflicts automatically resolved by simply
omitting the atomic change that conflicts.  In other cases, however,
you might want to pull in the original patches, or at least be
informed that they exist.