[darcs-users] Fwd: Darcs Problems

[John Lato]

On Sat, Mar 2, 2013 at 1:03 PM, Stephen J. Turnbull <
turnbull at sk.tsukuba.ac.jp> wrote:

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

A single git rebase doesn't usually take much time.  But when you have
developers advocating a rebase before every push, and a rebase on every
pull (even with pull --rebase), in addition to a number of other rebases in
the standard workflow, they add up.

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?


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


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

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.


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

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

1) a stable starting point for a single changeset
2) a mechanism to keep track of the derivation of hotfix' (possibly,
haven't given this one much thought)

A different darcs-pull that simply disregards meta-data may be simpler
though.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20130304/2cae203d/attachment.html>