diff options
author | Greg Myers <gmyers@gitlab.com> | 2022-01-27 13:59:18 +0300 |
---|---|---|
committer | Sami Hiltunen <shiltunen@gitlab.com> | 2022-01-27 13:59:18 +0300 |
commit | 93477502c35093dc708db35e1c2cedb9a4b4d387 (patch) | |
tree | f76adf21b96ad35eb0fec4ef16e0f9442c2e8e84 /doc | |
parent | 4b380e760d37508a2dc3c8e6a8fe1cfaae846916 (diff) |
Fix typos in gitaly docs
Diffstat (limited to 'doc')
-rw-r--r-- | doc/PROCESS.md | 2 | ||||
-rw-r--r-- | doc/design_ha.md | 6 | ||||
-rw-r--r-- | doc/object_pools.md | 2 |
3 files changed, 5 insertions, 5 deletions
diff --git a/doc/PROCESS.md b/doc/PROCESS.md index 92fa86b82..4f401f790 100644 --- a/doc/PROCESS.md +++ b/doc/PROCESS.md @@ -454,7 +454,7 @@ In order to add a patch, you can simply add it to the `GIT_PATCHES` array in our `Makefile`. Note: while there is only a single git distribution which is distributed across -all of GitLab's official distributions, there may be unoffical ones which use a +all of GitLab's official distributions, there may be unofficial ones which use a different version of git (most importantly source-based installations). So even if you add patches to Gitaly's Makefile, you cannot assume that installations will always have these patches. As a result, all code which makes use of diff --git a/doc/design_ha.md b/doc/design_ha.md index 51ba8db90..259584947 100644 --- a/doc/design_ha.md +++ b/doc/design_ha.md @@ -91,7 +91,7 @@ Praefect relies on replication when a Gitaly RPC doesn't support transactions or a repository replica needs to be repaired. For transaction mutator RPCs, Praefect attempts to make the same change to a -quroum of a repository replicas in a single transactional write. If a quorom of replicas +quorum of repository replicas in a single transactional write. If a quorum of replicas successfully applies the RPC, then replication will only be scheduled for any replicas that were unsuccessful. See the section on [strong consistency design](#strong-consistency-design) for more details. @@ -202,7 +202,7 @@ When the beta nears completion further stages will be defined. ## Eventual consistency -The beta implemention above describes an eventually consistent system: +The beta implementation above describes an eventually consistent system: when a repository is modified, the secondaries asynchronously fetch the changes. This is similar to how Geo works today: @@ -567,7 +567,7 @@ v13.1.0-rc3. * Complications * Existing Rails app indicates the Gitaly instance that a request is destined for (e.g. request to modify repo X should be directed to gitaly #1). * This means that rails app must be kept in the loop about any changes made to the location of a repo. - * This may be mitigated by changing the proxy implementation to intepret the destination address as a reference to a shard rather than a specific host. This might open the door to allowing for something like consistent hashing. + * This may be mitigated by changing the proxy implementation to interpret the destination address as a reference to a shard rather than a specific host. This might open the door to allowing for something like consistent hashing. * While Git is distributed in nature, some write operations need to be serialized to avoid race conditions. This includes ref updates. * How do we coordinate proxies when applying ref updates? Do we need to? diff --git a/doc/object_pools.md b/doc/object_pools.md index c551f8e6f..f28ae423b 100644 --- a/doc/object_pools.md +++ b/doc/object_pools.md @@ -45,7 +45,7 @@ file. ### Housekeeping Housekeeping for object pools is handled differently from normal repositories as -it not only involves repacking the pool, but also updating it. The houskeeping +it not only involves repacking the pool, but also updating it. The housekeeping task is thus hosted by the `FetchIntoObjectPool` RPC. This task is typically only executed with the original object pool member from which the pool has been seeded and updates the pool by fetching from that member. |