darcs

Safe HaskellSafe-Infered

Darcs.Patch.Depends

Synopsis

Documentation

getTagsRight :: PatchSet p -> [PatchInfo]

getTagsRight ps returns the PatchInfo for all the patches in ps that are not depended on by anything else *through explicit dependencies*. Tags are a likely candidate, although we may also find some non-tag patches in this list.

Keep in mind that in a typical repository with a lot of tags, only a small fraction of tags would be returned as they would be at least indirectly depended on by the topmost ones.

optimizePatchset :: PatchSet p -> PatchSet p

optimizePatchset is similar to slightlyOptimizePatchset in that it only works on the surface inventory (see below), but it works a bit harder and can optimize several tags.

  • surface inventory: the sequence of patches that corresponds to the _darcshashed\_inventory@ or @\_darcsinventory files
  • deep inventory: the sequence of sequences of patches that corresponds to the _darcs/inventories directory

deepOptimizePatchset :: PatchSet p -> PatchSet p

deepOptimizePatchset runs through all patches whether they are in the surface inventory or the deep one.

slightlyOptimizePatchset :: PatchSet p -> PatchSet p

slightlyOptimizePatchset only works on the surface inventory (see optimizePatchset) and only optimises at most one tag in there, going for the most recent tag which has no non-depended patch after it. Older tags won't be clean, which means the PatchSet will not be in 'unclean :< clean' state.

getPatchesInTag :: RepoPatch p => PatchInfo -> PatchSet p -> SealedPatchSet p

getPatchesInTag t ps returns a SealedPatchSet of all patches in ps which are contained in t.

merge2FL :: RepoPatch p => FL (PatchInfoAnd p) -> FL (PatchInfoAnd p) -> Sealed (FL (PatchInfoAnd p))

Merge two FLs (say L and R), starting in a common context. The result is a FL starting in the original end context of L, going to a new context that is the result of applying all patches from R on top of patches from L.

While this function is similar to mergeFL, there are three important differences to keep in mind:

  • mergeFL does not correctly deal with duplicate patches whereas this one does (Question from Eric Kow: in what sense? Why not fix the mergeFL instance?)
  • mergeFL returns both paths of the merge diamond, but this version only returns one, so you'd better choose the order carefully, eg. (merge2FL l r)
  • The conventional order we use in this function is reversed from mergeFL (so mergeFL r l vs. merge2FL l r. This does not matter so much for the former since you get both paths. (Question from Eric Kow: should we flip merge2FL for more uniformity in the code?)