A Repository is a token representing the state of a repository on disk. It is parameterized by the patch type in the repository, and witnesses for the recorded state of the repository (i.e. what darcs get would retrieve), the unrecorded state (what's in the working tree now), and the tentative state, which represents work in progress that will eventually become the new recorded state unless something goes wrong.

Cache is an abstract type for hiding the underlying cache locations

Prints an error message with a list of bad caches.

A RepoJob wraps up an action to be performed with a repository. Because repositories can contain different types of patches, such actions typically need to be polymorphic in the kind of patch they work on. RepoJob is used to wrap up the polymorphism, and the various functions that act on a RepoJob are responsible for instantiating the underlying action with the appropriate patch type.

Tries to identify the repository in a given directory

identifyRepositoryFor repo url identifies (and returns) the repo at url, but fails if it is not compatible for reading from and writing to.

Apply a given RepoJob to a repository in the current working directory. However, before doing the job, take the repo lock and initializes a repo transaction, unless this is a dry-run.

Apply a given RepoJob to a repository in the current working directory, taking a lock. If lock not takeable, do nothing. If old-fashioned repository, do nothing. The job must not touch pending or pending.tentative, because there is no call to revertRepositoryChanges. This entry point is currently only used for attemptCreatePatchIndex.

apply a given RepoJob to a repository in the current working directory

apply a given RepoJob to a repository in a given url

Replace the existing pristine with a new one (loaded up in a Tree object).

Read inventories and patches from a repository and return them as a PatchSet. Note that patches and inventories are read lazily.

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.

Add an FL of patches started from the pending state to the pending patch. TODO: add witnesses for pending so we can make the types precise: currently the passed patch can be applied in any context, not just after pending.

tentativelyAddToPending repo ps appends ps to the pending patch.

This fuction is unsafe because it accepts a patch that works on the tentative pending and we don't currently track the state of the tentative pending.

readRepo returns the tentative repo patchset.

Slightly confusingly named: as well as throwing away any tentative changes, revertRepositoryChanges also re-initialises the tentative state. It's therefore used before makign any changes to the repo.

Atomically copy the tentative state to the recorded state, thereby committing the tentative changes that were made so far. This includes inventories, pending, and the index.

grab the pristine hash of _darcs/hash_inventory, and retrieve whole pristine tree, possibly writing a clean working tree in the process.

Used by the commands dist and diff

Writes out a fresh copy of the inventory that minimizes the amount of inventory that need be downloaded when people pull from the repository.

Specifically, it breaks up the inventory on the most recent tag. This speeds up most commands when run remotely, both because a smaller file needs to be transfered (only the most recent inventory). It also gives a guarantee that all the patches prior to a given tag are included in that tag, so less commutation and history traversal is needed. This latter issue can become very important in large repositories.

The patches in a repository are stored in chunks broken up at "clean" tags. A tag is clean if the only patches before it in the current repository ordering are ones that the tag depends on (either directly or indirectly). Each chunk is stored in a separate inventory file on disk.

A PatchSet represents a repo's history as the list of patches since the last clean tag, and then a list of patch lists each delimited by clean tags.

Because the invariants about clean tags can only be maintained if a PatchSet contains the whole history, the first witness is always forced to be Origin. The type still has two witnesses so it can easily be used with combinators like :> and Fork.

The history is lazily loaded from disk so does not normally need to be all kept in memory.

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.

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.

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

Obtains the recorded Tree with the pending patch applied.

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.)