- restrictSubpaths :: RepoPatch p => Repository p -> [SubPath] -> IO (forall t m. FilterTree t m => t m -> t m)
- restrictBoring :: forall t m. Tree m -> IO (FilterTree t m => t m -> t m)
- unrecordedChanges :: RepoPatch p => [DarcsFlag] -> Repository p -> [SubPath] -> IO (FL Prim)
- readPending :: RepoPatch p => Repository p -> IO (Tree IO, Sealed (FL Prim))
- pendingChanges :: RepoPatch p => Repository p -> [SubPath] -> IO (Sealed (FL Prim))
- readRecorded :: RepoPatch p => Repository p -> IO (Tree IO)
- readUnrecorded :: RepoPatch p => Repository p -> IO (Tree IO)
- readRecordedAndPending :: RepoPatch p => Repository p -> IO (Tree IO)
- readIndex :: RepoPatch p => Repository p -> IO Index
- invalidateIndex :: t -> IO ()
Documentation
restrictSubpaths :: RepoPatch p => Repository p -> [SubPath] -> IO (forall t m. FilterTree t m => t m -> t m)Source
From a repository and a list of SubPath'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. As an exception for convenience, if the subpath list is empty, the filter constructed is an identity.
restrictBoring :: forall t m. Tree m -> IO (FilterTree t m => t m -> t m)Source
Construct a Tree filter that removes any boring files the Tree might have contained. Additionally, you should (in most cases) pass an (expanded) Tree that corresponds to the recorded content of the repository. This is important in the cases when the repository contains files that would be boring otherwise. (If you pass emptyTree instead, such files will simply be discarded by the filter, which is usually not what you want.)
This function is most useful when you have a plain Tree corresponding to the full working copy of the repository, including untracked files. Cf. whatsnew, record --look-for-adds. NB. Assumes that our CWD is the repository root.
Diffs.
unrecordedChanges :: RepoPatch p => [DarcsFlag] -> Repository p -> [SubPath] -> IO (FL Prim)Source
For a repository and a list of paths (when empty, 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 copy + pending). When a non-empty list of paths is given, exactly the files that live under any of these paths in either recorded or unrecorded will be included in the resulting patch.
This also depends on the options given: with LookForAdds, we will include any non-boring files (i.e. also those that do not exist in the recorded state) in the working in the unrecorded state, and therefore they will show up in the patches as addfiles.
The IgnoreTimes option 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).
readPending :: RepoPatch p => Repository p -> IO (Tree IO, Sealed (FL Prim))Source
pendingChanges :: RepoPatch p => Repository p -> [SubPath] -> IO (Sealed (FL Prim))Source
Trees.
readRecorded :: RepoPatch p => Repository p -> IO (Tree IO)Source
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.
Handles the plain and hashed pristine cases. Currently does not handle the
no-pristine case, as that requires replaying patches. Cf. readDarcsHashed
and readPlainTree
in hashed-storage that are used to do the actual Tree
construction.
readUnrecorded :: RepoPatch p => Repository p -> IO (Tree IO)Source
Obtains a Tree corresponding to the unrecorded state of the repository: the working tree plus the pending patch.
readRecordedAndPending :: RepoPatch p => Repository p -> IO (Tree IO)Source
Index.
invalidateIndex :: t -> IO ()Source
Mark the existing index as invalid. This has to be called whenever the listing of pristine changes and will cause darcs to update the index next time it tries to read it. (NB. This is about files added and removed from pristine: changes to file content in either pristine or working are handled transparently by the index reading code.)