|
|
|
|
|
|
Synopsis |
|
|
|
Documentation |
|
|
Instances | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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 and the new repository is not in hashed format.
This function does not (yet) work for hashed repositories. If the passed DarcsFlags tell
darcs to create a hashed repository, this function will call error.
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
A PatchSet is in reverse order, plus has information about which
tags are clean, meaning all patches applied prior to them are in
the tag itself, so we can stop reading at that point. Just to
clarify, the first patch in a PatchSet is the one most recently
applied to the repo.
PatchSets have the property that if
(info $ last $ head a) == (info $ last $ head b)
then (tail a) and (tail b) are identical repositories
Questions:
Does this mean that in a patch set such as [[a b t1 c d e t2][f g
t3] [h i]], t1, t2 and t3 are tags, and t2 and t3 are clean?
Can we have PatchSet with length at least 3?
Florent
|
|
|
|
|
PatchInfoAnd p 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.
| Instances | |
|
|
|
Sets scripts in or below the current directory executable. A script is any file that starts
with the bytes '#!'. This is used sometimes for --set-scripts-executable, but at other times
--set-scripts-executable is handled by the hunk patch case of applyFL.
|
|
|
|
|
|
|
|
Recorded and unrecorded and pending.
|
|
|
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.
|
|
|
Obtains a Tree corresponding to the unrecorded state of the repository:
the working tree plus the pending patch.
|
|
|
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).
|
|
|
|
|
|
|
|
Index.
|
|
|
|
|
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.)
|
|
Produced by Haddock version 2.4.2 |