@recaptime-dev's working patches + fork for Phorge, a community fork of Phabricator. (Upstream dev and stable branches are at upstream/main and upstream/stable respectively.)
hq.recaptime.dev/wiki/Phorge
phorge
phabricator
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
+3
-3
+3
-3
src/docs/user/cluster/cluster_repositories.diviner
+3
-3
src/docs/user/cluster/cluster_repositories.diviner
···
37
37
version check and fetch if necessary, then allow the write to continue.
38
38
39
39
Additionally, repositories passively check other nodes for updates and
40
-
replicate changes in the background. After you push a change to a repositroy,
40
+
replicate changes in the background. After you push a change to a repository,
41
41
it will usually spread passively to all other repository nodes within a few
42
42
minutes.
43
43
···
381
381
382
382
Here, all of the "leader" devices with the most up-to-date copy of the
383
383
repository have been lost. Phabricator will freeze the repository refuse to
384
-
serve requests because it can not serve it consistently, and can not accept new
385
-
writes without data loss.
384
+
serve requests because it can not serve reads consistently and can not accept
385
+
new writes without data loss.
386
386
387
387
The most straightforward way to resolve this issue is to restore any leader to
388
388
service. The change will be able to replicate to other devices once a leader