You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@couchdb.apache.org by fl...@apache.org on 2020/10/12 08:13:07 UTC
[couchdb-documentation] branch main updated: More inclusive
terminology pt 1 (#599)
This is an automated email from the ASF dual-hosted git repository.
flimzy pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/couchdb-documentation.git
The following commit(s) were added to refs/heads/main by this push:
new ac84181 More inclusive terminology pt 1 (#599)
ac84181 is described below
commit ac8418183d5c22556f4e2ea12872ff1a444a6938
Author: Simon Dahlbacka <si...@ecraft.com>
AuthorDate: Mon Oct 12 11:12:59 2020 +0300
More inclusive terminology pt 1 (#599)
* use blocklist instead of Blacklist
* use allowlist instead of whitelist
* use main instead of master (when talking about branches)
---
src/config/auth.rst | 2 +-
src/config/indexbuilds.rst | 2 +-
src/replication/conflicts.rst | 38 +++++++++++++++++++-------------------
3 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/src/config/auth.rst b/src/config/auth.rst
index d0d5f5d..705c771 100644
--- a/src/config/auth.rst
+++ b/src/config/auth.rst
@@ -231,7 +231,7 @@ Authentication Configuration
public_fields = first_name, last_name, contacts, url
.. note::
- Using the ``public_fields`` whitelist for user document properties
+ Using the ``public_fields`` allowlist for user document properties
requires setting the :option:`couch_httpd_auth/users_db_public`
option to ``true`` (the latter option has no other purpose)::
diff --git a/src/config/indexbuilds.rst b/src/config/indexbuilds.rst
index fb406c7..103633c 100644
--- a/src/config/indexbuilds.rst
+++ b/src/config/indexbuilds.rst
@@ -49,7 +49,7 @@ following settings.
database. If the difference is larger than the threshold defined here the
background job will only be allowed to run in the main queue. Defaults to 1000.
-.. config:section:: ken.ignore :: Auto-Indexing Blacklist
+.. config:section:: ken.ignore :: Auto-Indexing Blocklist
Entries in this configuration section can be used to tell the background indexer to skip
over specific database shard files. The key must be the exact name of the shard with the
diff --git a/src/replication/conflicts.rst b/src/replication/conflicts.rst
index 2341fb9..67675dd 100644
--- a/src/replication/conflicts.rst
+++ b/src/replication/conflicts.rst
@@ -595,9 +595,9 @@ is an SHA1 hash of the tip commit.
If you are replicating with one or more peers, a separate branch is made for
each of those peers. For example, you might have::
- master -- my local branch
- remotes/foo/master -- branch on peer 'foo'
- remotes/bar/master -- branch on peer 'bar'
+ main -- my local branch
+ remotes/foo/main -- branch on peer 'foo'
+ remotes/bar/main -- branch on peer 'bar'
In the regular workflow, replication is a "pull", importing changes from
a remote peer into the local repository. A "pull" does two things: first "fetch"
@@ -609,24 +609,24 @@ Now let's consider the business card. Alice has created a Git repo containing
this, where ``AAAAAAAA`` is the SHA1 of the commit::
---------- desktop ---------- ---------- laptop ----------
- master: AAAAAAAA master: AAAAAAAA
- remotes/laptop/master: AAAAAAAA remotes/desktop/master: AAAAAAAA
+ main: AAAAAAAA main: AAAAAAAA
+ remotes/laptop/main: AAAAAAAA remotes/desktop/main: AAAAAAAA
Now she makes a change on the desktop, and commits it into the desktop repo;
then she makes a different change on the laptop, and commits it into the laptop
repo::
---------- desktop ---------- ---------- laptop ----------
- master: BBBBBBBB master: CCCCCCCC
- remotes/laptop/master: AAAAAAAA remotes/desktop/master: AAAAAAAA
+ main: BBBBBBBB main: CCCCCCCC
+ remotes/laptop/main: AAAAAAAA remotes/desktop/main: AAAAAAAA
Now on the desktop she does ``git pull laptop``. First, the remote objects
are copied across into the local repo and the remote tracking branch is
updated::
---------- desktop ---------- ---------- laptop ----------
- master: BBBBBBBB master: CCCCCCCC
- remotes/laptop/master: CCCCCCCC remotes/desktop/master: AAAAAAAA
+ main: BBBBBBBB main: CCCCCCCC
+ remotes/laptop/main: CCCCCCCC remotes/desktop/main: AAAAAAAA
.. note::
The repo still contains AAAAAAAA because commits BBBBBBBB and CCCCCCCC
@@ -639,15 +639,15 @@ the parent commit to ``CCCCCCCC`` is ``AAAAAAAA``, it takes a diff between
If this is successful, then you'll get a new version with a merge commit::
---------- desktop ---------- ---------- laptop ----------
- master: DDDDDDDD master: CCCCCCCC
- remotes/laptop/master: CCCCCCCC remotes/desktop/master: AAAAAAAA
+ main: DDDDDDDD main: CCCCCCCC
+ remotes/laptop/main: CCCCCCCC remotes/desktop/main: AAAAAAAA
Then Alice has to logon to the laptop and run ``git pull desktop``. A similar
process occurs. The remote tracking branch is updated::
---------- desktop ---------- ---------- laptop ----------
- master: DDDDDDDD master: CCCCCCCC
- remotes/laptop/master: CCCCCCCC remotes/desktop/master: DDDDDDDD
+ main: DDDDDDDD main: CCCCCCCC
+ remotes/laptop/main: CCCCCCCC remotes/desktop/main: DDDDDDDD
Then a merge takes place. This is a special case: ``CCCCCCCC`` is one of the
parent commits of ``DDDDDDDD``, so the laptop can `fast forward` update from
@@ -655,8 +655,8 @@ parent commits of ``DDDDDDDD``, so the laptop can `fast forward` update from
This leaves the final state as::
---------- desktop ---------- ---------- laptop ----------
- master: DDDDDDDD master: DDDDDDDD
- remotes/laptop/master: CCCCCCCC remotes/desktop/master: DDDDDDDD
+ main: DDDDDDDD main: DDDDDDDD
+ remotes/laptop/main: CCCCCCCC remotes/desktop/main: DDDDDDDD
Now this is all and good, but you may wonder how this is relevant when thinking
about CouchDB.
@@ -678,10 +678,10 @@ multiple remote tracking branches, some of which may match your local branch,
some of which may be behind you, and some of which may be ahead of you
(i.e. contain changes that you haven't yet merged)::
- master: AAAAAAAA
- remotes/foo/master: BBBBBBBB
- remotes/bar/master: CCCCCCCC
- remotes/baz/master: AAAAAAAA
+ main: AAAAAAAA
+ remotes/foo/main: BBBBBBBB
+ remotes/bar/main: CCCCCCCC
+ remotes/baz/main: AAAAAAAA
Note that each peer is explicitly tracked, and therefore has to be explicitly
created. If a peer becomes stale or is no longer needed, it's up to you to