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.

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

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.

patchSetToRepository takes a patch set, and writes a new repository in the current directory that contains all the patches in the patch set. This function is used when 'darcs get'ing a repository with the --to-match flag.

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

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

Obtains a Tree corresponding to the recorded state of the repository and a pending patch to go with it. 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 same Tree as readRecorded would but with the additional side effect of reading/checking the pending patch.

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

Get a list of all files and directories in the working copy, including boring files if necessary

listRegisteredFiles returns the list of all registered files in the repository.

listUnregisteredFiles returns the list of all non-boring unregistered files in the repository.