From a repository and a list of AnchoredPath's, construct a filter that can be used on a Tree (recorded or unrecorded state) of this repository. This constructed filter will take pending into account, so the subpaths will be translated correctly relative to pending move patches.

Construct a TreeFilter that removes any boring files that are not also contained in the argument Tree.

The standard use case is for the argument to be the recorded state, possibly with further patches applied, so as not to discard any files already known to darcs. The result is usually applied to the full working state.

Construct a Tree filter that removes any darcs metadata files the Tree might have contained.

For a repository and an optional list of paths (when Nothing, take everything) compute a (forward) list of prims (i.e. a patch) going from the recorded state of the repository (pristine) to the unrecorded state of the repository (the working tree + pending). When a list of paths is given, at least the files that live under any of these paths in either recorded or unrecorded will be included in the resulting patch. NB. More patches may be included in this list, eg. the full contents of the pending patch. This is usually not a problem, since selectChanges will properly filter the results anyway.

This also depends on the options given:

• -look-for-moves: Detect pending file moves using the index. The resulting patches are added to pending and taken into consideration, when filtering the tree according to the given path list.
• -look-for-adds: Include files in the working state that do not exist in the recorded + pending state.
• -include-boring: Include even boring files.
• -look-for-replaces: Detect pending replace patches. Like detected moves, these are added to the pending patch. Note that, like detected moves, these are mere proposals for the user to consider or reject.
• -ignore-times: Disables index usage completely -- for each file, we read both the unrecorded and the recorded copy and run a diff on them. This is very inefficient, although in extremely rare cases, the index could go out of sync (file is modified, index is updated and file is modified again within a single second).

Note that use of the index is also disabled when we detect moves or replaces, since this implies that the index is out of date.

Obtains a Tree corresponding to the "recorded" state of the repository: this is the same as the pristine cache, which is the same as the result of applying all the repository's patches to an empty directory.

Obtains a Tree corresponding to the "unrecorded" state of the repository: the modified files of the working tree plus the "pending" patch. The optional list of paths allows to restrict the query to a subtree.

Limiting the query may be more efficient, since hashes on the uninteresting parts of the index do not need to go through an up-to-date check (which involves a relatively expensive lstat(2) per file.

Obtains the recorded Tree with the pending patch applied.

Obtains the relevant (according to the given filter) part of the working tree.

A variant of readUnrecorded that takes the UseIndex and LookForAdds options into account, similar to readPendingAndWorking. We are only interested in the resulting tree, not the patch, so the DiffAlgorithm option is irrelevant.

Open the index or re-create it in case it is invalid or non-existing.

Update the index so that it matches pristine+pending. If the index does not exist or is invalid, create a new one.

This has to be called whenever the listing of pristine+pending changes. Note that this only concerns files added and removed or renamed: changes to file content in either pristine or working are handled transparently by the index reading code.

Remove any patches (+dependencies) from a sequence that conflict with the recorded or unrecorded changes in a repo

Add an FL of patches started from the pending state to the pending patch.

Add an FL of patches starting from the working state to the pending patch, including as much extra context as is necessary (context meaning dependencies), by commuting the patches to be added past as much of the changes between pending and working as is possible, and including anything that doesn't commute, and the patch itself in the new pending patch.