[darcs-devel] darcs patch: fix typo (and 3 more)

[Tommy Pettersson]

On Sun, Aug 05, 2007 at 12:49:54PM +0200, Eric Y. Kow wrote:
> > Maybe more controversial, it "works" for Unrecord / Unpull /
> > Obliterate too, as in the meaning of 'deps' is reversed:
> 
> Tommy, it might be worth adding this to the doc.

Yes. I'll see what I can do. I'm thinking of writing some
regression tests too.

> My view is a little hazy on this.  I suspect I'm missing out on how the

Mine too, but here's what I get. (This is the big picture. There
are many clever details to get stuck on.)

I imagine the first-middle-last thing as balls on a wire
(somewhat like an abacus) painted in three colors (first, middle
and last). Some balls can pass right through some of the others
(commute), and some can not. If you drag one ball from (e.g.)
middle to last it will pass through some balls but force some
other balls with it. If you drag it right back again the forced
balls will stay in last until dragged or forced elsewhere.

Selecting dependency constrained patches (dividing them into
_two_ groups) is always a two step operation. Step 1: drag them
around on the wire. Step 2: separate the wire at one of the two
color junctions, [first / middle-+last] or [first+middle / last]
(it's not always obvious in the code which one of the two pieces
is the "selected" one).

A whole two-step selection operation is performed twice during a
normal Pull or Unpull (at top level -- sub selections performed
during the top selection, like deal_with_fs, does them too). The
first top level selection is when we automatically select some
patches per the command line options and arguments, to narrow
down the list. The second one is the interactive dialogue.

During the first (automatic) selection (and all the sub
selections) the middle part of the wire doesn't have any real
meaning. We can drag patches and separate them as we like, as
long as we come up with the right selection.

This selection is then passed to the dialogue, where middle has
the somewhat clearer meaning of undecided. Although I would like
to change that, lower one end of the wire, so that undecided
patches are pulled by gravity towards No, and can be thought of
as "only if needed".

> (ii) we demote all the choices (selected patches
> become undecided, and undecided patches become unselected; i don't yet
> understand why we do this).

This is the automatic selection. There we (by undocumented
design) always force everything we don't want either into
'first' or 'last' (depending on 'islast'), and then separate out
the other two parts (everything we want). This must be uniformly
obeyed by all selection steps in patches_to_consider.


-- 
Tommy Pettersson <ptp at lysator.liu.se>