Patchwork D11747: internals: typo pass on the dirstate-v2 help file

login
register
mail settings
Submitter phabricator
Date Nov. 10, 2021, 10:47 a.m.
Message ID <differential-rev-PHID-DREV-7ut7och7dybqd4qiaeem-req@mercurial-scm.org>
Download mbox | patch
Permalink /patch/50071/
State Superseded
Headers show

Comments

phabricator - Nov. 10, 2021, 10:47 a.m.
Alphare created this revision.
Alphare added a comment.
Herald added a reviewer: hg-reviewers.
Herald added a subscriber: mercurial-patches.


  Pending CI refresh

REPOSITORY
  rHG Mercurial

BRANCH
  stable

REVISION DETAIL
  https://phab.mercurial-scm.org/D11747

AFFECTED FILES
  mercurial/helptext/internals/dirstate-v2.txt

CHANGE DETAILS




To: Alphare, #hg-reviewers
Cc: mercurial-patches, mercurial-devel

Patch

diff --git a/mercurial/helptext/internals/dirstate-v2.txt b/mercurial/helptext/internals/dirstate-v2.txt
--- a/mercurial/helptext/internals/dirstate-v2.txt
+++ b/mercurial/helptext/internals/dirstate-v2.txt
@@ -12,7 +12,7 @@ 
 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
@@ -33,7 +33,7 @@ 
 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`,
@@ -44,7 +44,7 @@ 
 
     $ 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
@@ -96,7 +96,7 @@ 
 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.
@@ -108,7 +108,7 @@ 
 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}`,
@@ -173,7 +173,7 @@ 
 * 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.
 
@@ -303,15 +303,15 @@ 
 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.
@@ -418,7 +418,7 @@ 
   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,
@@ -503,8 +503,8 @@ 
     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
-      does not indicate the lack of directory on the file system.
+      `mtime` matches its last modification time. However, `HAS_MTIME` not
+      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.
@@ -562,8 +562,8 @@ 
     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
-    that is will be all of them.
+    children have been recorded. Some might be present, but there is
+    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
@@ -575,8 +575,8 @@ 
     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
-    that is will be all of them.
+    children have been recorded. Some might be present, but there is
+    no guarantee that is will be all of them.
 
 `HAS_FALLBACK_EXEC`
     If this flag is set, the entry carries "fallback" information for the
@@ -612,5 +612,5 @@ 
     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.