|
|
|
Description |
PatchChoices divides a sequence of patches into three sets: first,
middle and last, such that all patches can be applied, if you first
apply the first ones then the middle ones and then the last ones.
Obviously if there are dependencies between the patches that will put a
constraint on how you can choose to divide them up. The PatchChoices data
type and associated functions are here to deal with many of the common
cases that come up when choosing a subset of a group of patches.
forceLast tells PatchChoices that a particular patch is required to be in
the last group, which also means that any patches that depend on it
must be in the last group.
Internally, a PatchChoices doesn't always reorder the patches until
it is asked for the final output (e.g. by get_first_choice).
Instead, each patch is placed in a state of definitely first,
definitely last and undecided; undecided leans towards
middle. The patches that are first are commuted to the head
immediately, but patches that are middle and last are mixed
together. In case you're wondering about the first-middle-last
language, it's because in some cases the yes answers will be last
(as is the case for the revert command), and in others first (as in
record, pull and push).
Some patch marked middle may in fact be unselectable because of
dependencies: when a patch is marked last, its dependencies are
not updated until patchSlot is called on them.
|
|
Synopsis |
|
|
|
Documentation |
|
|
|
|
|
|
Tag a sequence of patches.
|
|
|
Tag a sequence of patches as subpatches of an existing tag. This is intended for
use when substituting a patch for an equivalent patch or patches.
|
|
|
|
|
|
|
getChoices evaluates a PatchChoices into the first, middle and last sequences
by doing the commutes that were needed.
|
|
|
refineChoices act performs act on the middle part of a sequence
of choices, in order to hopefully get more patches into the first and
last parts of a PatchChoices.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Instances | |
|
|
|
TG mp i acts as a temporary identifier to help us keep track of patches
during the selection process. These are useful for finding patches that
may have moved around during patch selection (being pushed forwards or
backwards as dependencies arise).
The identifier is implemented as a tuple TG mp i. The i is just some
arbitrary label, expected to be unique within the patches being
scrutinised. The mp is motivated by patch splitting; it
provides a convenient way to generate a new identifier from the patch
being split. For example, if we split a patch identified as TG Nothing
5, the resulting sub-patches could be identified as TG (TG Nothing 5)
1, TG (TG Nothing 5) 2, etc.
| Instances | |
|
|
|
|
|
|
|
See module documentation for Darcs.Patch.Choices
| Constructors | |
|
|
|
substitute (a :||: bs) pcs replaces a with bs in pcs preserving the choice
associated with a
|
|
Produced by Haddock version 2.6.1 |