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 directory 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

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, taking a lock

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

writePatchSet is like patchSetToRepository, except that it doesn't touch the working directory or pristine cache.

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

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 NoDryRun YesUpdateWorking pend ps appends ps to the pending patch.

It has no effect with NoUpdateWorking.

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.

Some common flags that are needed to run rebase jobs. Normally flags are captured directly by the implementation of the specific job's function, but the rebase infrastructure needs to do work on the repository directly that sometimes needs these options, so they have to be passed as part of the job definition.

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. So the type should rather be

... -> Repo rt p wR wU wT -> IO (Repo rt p wR wU wR)

grab the pristine hash of _darcs/hash_inventory, and retrieve whole pristine tree, possibly writing a clean working copy 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.

PatchInfoAnd p wA wB represents a hope we have to get a patch through its info. We're not sure we have the patch, but we know its info.

modifyCache repository function modifies the cache of repository with function, remove duplicates and sort the results with compareByLocality.

Prints an error message with a list of bad caches.

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 copy + 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, plus the pending patch itself. The pending patch should start at the recorded state (we even verify that it applies, and degrade to renaming pending and starting afresh if it doesn't), but we've set to say it starts at the tentative state.

Question (Eric Kow) Is this a bug? Darcs.Repository.Pending.readPending says it is

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