mercurial: comparison mercurial/helptext/internals/dirstate-v2.txt

equal deleted inserted replaced

-:f35529784079
+:6248607381f2
 is described at https://www.mercurial-scm.org/wiki/DirState.
 It is made of a flat sequence of unordered variable-size entries,
 so accessing any information in it requires parsing all of it.
 Similarly, saving changes requires rewriting the entire file.
-The newer `dirsate-v2` file format is designed to fix these limitations
+The newer `dirstate-v2` file format is designed to fix these limitations
 and make `hg status` faster.
 User guide
 ==========
 `dirstate-v2` does not affect compatibility with remote Mercurial versions.
 When `share-safe` is enabled, different repositories sharing the same store
 can use different dirstate formats.
-Enabling `dirsate-v2` for new local repositories
+Enabling `dirstate-v2` for new local repositories
 ------------------------------------------------
 When creating a new local repository such as with `hg init` or `hg clone`,
 the `exp-rc-dirstate-v2` boolean in the `format` configuration section
 controls whether to use this file format.
 This is disabled by default as of this writing.
 To enable it for a single repository, run for example::
 $ hg init my-project --config format.exp-rc-dirstate-v2=1
-Checking the format of an existing local repsitory
+Checking the format of an existing local repository
 --------------------------------------------------
 The `debugformat` commands prints information about
 which of multiple optional formats are used in the current repository,
 including `dirstate-v2`::
 -----------------
 The `.hg/requires` file indicates which of various optional file formats
 are used by a given repository.
 Mercurial aborts when seeing a requirement it does not know about,
-which avoids older version accidentally messing up a respository
+which avoids older version accidentally messing up a repository
 that uses a format that was introduced later.
 For versions that do support a format, the presence or absence of
 the corresponding requirement indicates whether to use that format.
 When the file contains a `dirstate-v2` line,
 With no such line `dirstate-v1` is used.
 High level description
 ----------------------
-Whereas `dirstate-v1` uses a single `.hg/disrtate` file,
+Whereas `dirstate-v1` uses a single `.hg/dirstate` file,
 in `dirstate-v2` that file is a "docket" file
 that only contains some metadata
 and points to separate data file named `.hg/dirstate.{ID}`,
 where `{ID}` is a random identifier.
 be inlined here by adding 76 bytes to each offset.
 * Offset 120:
 The used size of the data file, as a 32-bit big-endian integer.
 The actual size of the data file may be larger
-(if another Mercurial processis in appending to it
+(if another Mercurial process is appending to it
 but has not updated the docket yet).
 That extra data must be ignored.
 * Offset 124:
 The length of the data file identifier, as a 8-bit integer.
 Paths and nodes can be organized in any order in the file, except that sibling
 nodes must be next to each other and sorted by their path.
 Contiguity lets the parent refer to them all
 by their count and a single pseudo-pointer,
 instead of storing one pseudo-pointer per child node.
-Sorting allows using binary seach to find a child node with a given name
+Sorting allows using binary search to find a child node with a given name
 in `O(log(n))` byte sequence comparisons.
-The current implemention writes paths and child node before a given node
+The current implementation writes paths and child node before a given node
 for ease of figuring out the value of pseudo-pointers by the time the are to be
 written, but this is not an obligation and readers must not rely on it.
 A path is stored as a byte string anywhere in the file, without delimiter.
-It is refered to by one or more node by a pseudo-pointer to its start, and its
+It is referred to by one or more node by a pseudo-pointer to its start, and its
 length in bytes. Since there is no delimiter,
 when a path is a substring of another the same bytes could be reused,
 although the implementation does not exploit this as of this writing.
 A node is stored on 43 bytes with components at fixed offsets. Paths and
 * Offset 40:
 The nanoseconds component of an `mtime` field described below,
 as a 32-bit integer.
 When `mtime` is used,
 this is the number of nanoseconds since `mtime.seconds`,
-always stritctly less than one billion.
+always strictly less than one billion.
 This may be zero if more precision is not available.
 (This can happen because of limitations in any of Mercurial, Python,
 libc, the operating system, …)
 `DIRECTORY`
 When set, this entry will match a directory that exists or existed on the
 file system.
 * When `HAS_MTIME` is set a directory has been seen on the file system and
-`mtime` matches its last modificiation time. However, `HAS_MTIME` not being set
+`mtime` matches its last modification time. However, `HAS_MTIME` not
-does not indicate the lack of directory on the file system.
+being set does not indicate the lack of directory on the file system.
 * When not tracked anywhere, this node does not represent an ignored or
 unknown file on disk.
 If `HAS_MTIME` is set
 Note that the amount recorded "unknown" children can still be zero if None
 where present.
 Also note that having this flag unset does not imply that no "unknown"
-children have been recorded. Some might be present, but there is no garantee
+children have been recorded. Some might be present, but there is
-that is will be all of them.
+no guarantee that is will be all of them.
 `ALL_IGNORED_RECORDED`
 If set, all "ignored" children existing on disk (at the time of the last
 status) have been recorded and the `mtime` associated with
 `DIRECTORY` can be used for optimization even when "ignored" file
 Note that the amount recorded "ignored" children can still be zero if None
 where present.
 Also note that having this flag unset does not imply that no "ignored"
-children have been recorded. Some might be present, but there is no garantee
+children have been recorded. Some might be present, but there is
-that is will be all of them.
+no guarantee that is will be all of them.
 `HAS_FALLBACK_EXEC`
 If this flag is set, the entry carries "fallback" information for the
 executable bit in the `FALLBACK_EXEC` flag.
 `MTIME_SECOND_AMBIGUOUS`
 This flag is relevant only when `HAS_FILE_MTIME` is set.  When set, the
 `mtime` stored in the entry is only valid for comparison with timestamps
 that have nanosecond information. If available timestamp does not carries
-nanosecond information, the `mtime` should be ignored and no optimisation
+nanosecond information, the `mtime` should be ignored and no optimization
 can be applied.

branch	stable
changeset 48322	6248607381f2
parent 48321	f35529784079
child 48674	f7086f6173f8