From 7ea1bd5a5a44361ebec617b0ae17e1fac965f711 Mon Sep 17 00:00:00 2001 From: epriestley Date: Mon, 9 Jan 2017 17:40:42 -0800 Subject: [PATCH] Fix two cluster repository documentation typos Summary: Ref T12087. Caught these while re-reading. Test Plan: O.O Reviewers: chad Reviewed By: chad Maniphest Tasks: T12087 Differential Revision: https://secure.phabricator.com/D17167 --- src/docs/user/cluster/cluster_repositories.diviner | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/docs/user/cluster/cluster_repositories.diviner b/src/docs/user/cluster/cluster_repositories.diviner index e7e8031677..463814c890 100644 --- a/src/docs/user/cluster/cluster_repositories.diviner +++ b/src/docs/user/cluster/cluster_repositories.diviner @@ -37,7 +37,7 @@ Before responding to a write, replicas obtain a global lock, perform the same version check and fetch if necessary, then allow the write to continue. Additionally, repositories passively check other nodes for updates and -replicate changes in the background. After you push a change to a repositroy, +replicate changes in the background. After you push a change to a repository, it will usually spread passively to all other repository nodes within a few minutes. @@ -381,8 +381,8 @@ this: Here, all of the "leader" devices with the most up-to-date copy of the repository have been lost. Phabricator will freeze the repository refuse to -serve requests because it can not serve it consistently, and can not accept new -writes without data loss. +serve requests because it can not serve reads consistently and can not accept +new writes without data loss. The most straightforward way to resolve this issue is to restore any leader to service. The change will be able to replicate to other devices once a leader