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 2017/10/23 17:12:20 UTC
[couchdb-documentation] 01/01: Spelling corrections and formatting
improvements
This is an automated email from the ASF dual-hosted git repository.
flimzy pushed a commit to branch spelling
in repository https://gitbox.apache.org/repos/asf/couchdb-documentation.git
commit 68ea6c36a02fab13b65e922c2d00f1feeec45893
Author: Jonathan Hall <fl...@flimzy.com>
AuthorDate: Mon Oct 23 12:02:54 2017 +0200
Spelling corrections and formatting improvements
---
src/api/basics.rst | 6 +++---
src/api/database/changes.rst | 2 +-
src/api/database/common.rst | 2 +-
src/api/ddoc/rewrites.rst | 20 ++++++++++----------
src/api/ddoc/views.rst | 6 +++---
src/api/document/attachments.rst | 4 ++--
src/api/document/common.rst | 10 +++++-----
src/api/server/common.rst | 6 +++---
src/cluster/databases.rst | 10 +++++-----
src/cluster/setup.rst | 35 +++++++++++++++++------------------
src/cluster/sharding.rst | 2 +-
src/cluster/theory.rst | 2 +-
src/config/auth.rst | 2 +-
src/config/http.rst | 8 ++++----
src/config/intro.rst | 2 +-
src/config/logging.rst | 2 +-
src/config/query-servers.rst | 2 +-
src/config/replicator.rst | 8 ++++----
src/config/services.rst | 2 +-
src/contributing.rst | 6 +++---
src/ddocs/ddocs.rst | 4 ++--
src/ddocs/views/collation.rst | 2 +-
src/ddocs/views/intro.rst | 2 +-
src/ddocs/views/nosql.rst | 2 +-
src/install/freebsd.rst | 2 +-
src/install/mac.rst | 2 +-
src/install/snap.rst | 2 +-
src/install/troubleshooting.rst | 10 +++++-----
src/install/upgrading.rst | 2 +-
src/intro/security.rst | 2 +-
src/intro/why.rst | 2 +-
src/json-structure.rst | 2 +-
src/maintenance/performance.rst | 8 ++++----
src/query-server/javascript.rst | 2 +-
src/replication/conflicts.rst | 32 ++++++++++++++++----------------
src/replication/intro.rst | 4 ++--
src/replication/protocol.rst | 4 ++--
src/replication/replicator.rst | 6 +++---
src/whatsnew/1.0.rst | 2 +-
src/whatsnew/1.1.rst | 2 +-
src/whatsnew/1.3.rst | 8 ++++----
src/whatsnew/2.0.rst | 2 +-
42 files changed, 120 insertions(+), 121 deletions(-)
diff --git a/src/api/basics.rst b/src/api/basics.rst
index b1d84f4..6b9b1d3 100644
--- a/src/api/basics.rst
+++ b/src/api/basics.rst
@@ -309,7 +309,7 @@ Number Handling
---------------
Developers and users new to computer handling of numbers often encounter
-suprises when expecting that a number stored in JSON format does not
+surprises when expecting that a number stored in JSON format does not
necessarily return as the same number as compared character by character.
Any numbers defined in JSON that contain a decimal point or exponent will be
@@ -452,7 +452,7 @@ refer to a single specific value that a double can represent.
The important point to understand is that we're mapping from one infinite set
onto a finite set. An easy way to see this is by reflecting on this::
- 1.0 == 1.00 == 1.000 = 1.(infinite zeroes)
+ 1.0 == 1.00 == 1.000 = 1.(infinite zeros)
Obviously a computer can't hold infinite bytes so we have to decimate our
infinitely sized set to a finite set that can be represented concisely.
@@ -472,7 +472,7 @@ input. Its behaving the same as any other common JSON library does, its just
not pretty printing its output.
On the other hand, if you actually are in a position where an IEEE-754 double
-is not a satisfactory datatype for your numbers, then the answer as has been
+is not a satisfactory data type for your numbers, then the answer as has been
stated is to not pass your numbers through this representation. In JSON this is
accomplished by encoding them as a string or by using integer types (although
integer types can still bite you if you use a platform that has a different
diff --git a/src/api/database/changes.rst b/src/api/database/changes.rst
index d48a9a6..41c581d 100644
--- a/src/api/database/changes.rst
+++ b/src/api/database/changes.rst
@@ -469,7 +469,7 @@ to the ``filter`` parameter, specifying the design document name and
GET /db/_changes?filter=design_doc/filtername HTTP/1.1
-Additionally, there are couple of builtin filters are available and described
+Additionally, a couple of built-in filters are available and described
below.
.. _changes/filter/doc_ids:
diff --git a/src/api/database/common.rst b/src/api/database/common.rst
index 5f696ab..3cb019f 100644
--- a/src/api/database/common.rst
+++ b/src/api/database/common.rst
@@ -421,7 +421,7 @@ respond with a HTTP :statuscode:`202` response code immediately.
documents will be successfully stored on disk. For example, individual
documents may not be saved due to conflicts, rejection by
:ref:`validation function <vdufun>` or by other reasons, even if overall
- the batch was sucessfully submitted.
+ the batch was successfully submitted.
**Request**:
diff --git a/src/api/ddoc/rewrites.rst b/src/api/ddoc/rewrites.rst
index ccb3542..4dbbca5 100644
--- a/src/api/ddoc/rewrites.rst
+++ b/src/api/ddoc/rewrites.rst
@@ -18,7 +18,7 @@
.. http:any:: /{db}/_design/{ddoc}/_rewrite/{path}
:synopsis: Rewrites HTTP request for the specified path by using stored
- array of routing rules or javascript function
+ array of routing rules or JavaScript function
Rewrites the specified path by rules defined in the specified design
document. The rewrite rules are defined in *array* or *string* field
@@ -44,7 +44,7 @@ Rewrite section a is stringified function
- **method** (*string*): Method of rewritten request. If omitted,
original request method is used
- **code** (*number*): Returned code. If provided, request is not rewritten
- and user immidiately receives response with the code
+ and user immediately receives response with the code
- **body** (*string*): Body for POST/PUT requests, or for returning to user
if *code* field provided. If POST/PUT request is being rewritten and no
body returned by rewrite function, original request body is used
@@ -101,11 +101,11 @@ Rewrite section is an array
Each rule is an *object* with next structure:
- - **from** (*string*): The path rule used to bind current uri to the rule.
- It use pattern matching for that
- - **to** (*string*): Rule to rewrite an url. It can contain variables
+ - **from** (*string*): The path rule used to bind current URI to the rule.
+ It uses pattern matching for that.
+ - **to** (*string*): Rule to rewrite a URL. It can contain variables
depending on binding variables discovered during pattern matching and
- query args (url args and from the query member)
+ query args (URL args and from the query member)
- **method** (*string*): HTTP request method to bind the request method to
the rule. Default is ``"*"``
- **query** (*object*): Query args you want to define they can contain
@@ -119,7 +119,7 @@ Rewrite section is an array
- This path is converted in Erlang list by splitting ``/``
- Each ``var`` are converted in atom
- ``""`` are converted to ``''`` atom
- - The pattern matching is done by splitting ``/`` in request url in a list
+ - The pattern matching is done by splitting ``/`` in request URL in a list
of token
- A string pattern will match equal token
- The star atom (``'*'`` in single quotes) will match any number of tokens,
@@ -132,7 +132,7 @@ Rewrite section is an array
method. It will then try to match the path to one rule. If no rule matches,
then a :statuscode:`404` response returned.
- Once a rule is found we rewrite the request url using the ``to`` and
+ Once a rule is found we rewrite the request URL using the ``to`` and
``query`` fields. The identified token are matched to the rule and will
replace var. If ``'*'`` is found in the rule it will contain the remaining
part if it exists.
@@ -140,7 +140,7 @@ Rewrite section is an array
Examples:
+-----------------------------------+----------+------------------+-------+
- | Rule | Url | Rewrite to | Tokens|
+ | Rule | URL | Rewrite to | Tokens|
+===================================+==========+==================+=======+
| {"from": "/a", | /a | /some | |
| "to": "/some"} | | | |
@@ -166,7 +166,7 @@ Rewrite section is an array
+-----------------------------------+----------+------------------+-------+
Request method, header, query parameters, request payload and response body
- are depended on endpoint to which url will be rewritten.
+ are depended on endpoint to which URL will be rewritten.
:param db: Database name
:param ddoc: Design document name
diff --git a/src/api/ddoc/views.rst b/src/api/ddoc/views.rst
index 98de8f8..f2349be 100644
--- a/src/api/ddoc/views.rst
+++ b/src/api/ddoc/views.rst
@@ -653,9 +653,9 @@ regenerated and new order applied.
Using Limits and Skipping Rows
==============================
-By default requestion views result returns all records for it. That's ok when
-they are small, but this may lead to problems when there are billions of them
-since the clients might have to read them all and consume all available memory.
+By default, views return all results. That's ok when the number of results is
+small, but this may lead to problems when there are billions results, since the
+client may have to read them all and consume all available memory.
But it's possible to reduce output result rows by specifying ``limit`` query
parameter. For example, retrieving the list of recipes using the ``by_title``
diff --git a/src/api/document/attachments.rst b/src/api/document/attachments.rst
index 5ed6d70..7d64289 100644
--- a/src/api/document/attachments.rst
+++ b/src/api/document/attachments.rst
@@ -37,7 +37,7 @@
<api/doc/attachment/range>`. Used for attachments with
:mimetype:`application/octet-stream` content type
:>header Content-Encoding: Used compression codec. Available if
- attachment's ``content_type`` is in :config:option:`list of compressiable
+ attachment's ``content_type`` is in :config:option:`list of compressible
types <attachments/compressible_types>`
:>header Content-Length: Attachment size. If compression codec was used,
this value is about compressed size, not actual
@@ -92,7 +92,7 @@
<api/doc/attachment/range>`. Used for attachments with
:mimetype:`application/octet-stream`
:>header Content-Encoding: Used compression codec. Available if
- attachment's ``content_type`` is in :config:option:`list of compressiable
+ attachment's ``content_type`` is in :config:option:`list of compressible
types <attachments/compressible_types>`
:>header Content-Length: Attachment size. If compression codec is used,
this value is about compressed size, not actual
diff --git a/src/api/document/common.rst b/src/api/document/common.rst
index c735c61..521c00e 100644
--- a/src/api/document/common.rst
+++ b/src/api/document/common.rst
@@ -512,7 +512,7 @@ Retrieving Attachments Content
------------------------------
It's possible to retrieve document with all attached files content by using
-``attachements=true`` query parameter:
+``attachments=true`` query parameter:
**Request**:
@@ -613,8 +613,8 @@ query parameter:
Efficient Multiple Attachments Retrieving
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-As you had noted above, retrieving document with ``attachements=true`` returns
-large JSON object where all attachments are included. While you document and
+As noted above, retrieving document with ``attachments=true`` returns a
+large JSON object with all attachments included. When your document and
files are smaller it's ok, but if you have attached something bigger like media
files (audio/video), parsing such response might be very expensive.
@@ -1007,8 +1007,8 @@ requested.
Retrieving Deleted Documents
----------------------------
-CouchDB doesn't actually deletes documents via :delete:`/{db}/{docid}`.
-Instead of this, it leaves tombstone with very basic information about
+CouchDB doesn't actually delete documents via :delete:`/{db}/{docid}`.
+Instead, it leaves tombstone with very basic information about the
document. If you just :get:`/{db}/{docid}` CouchDB returns :statuscode:`404`
response:
diff --git a/src/api/server/common.rst b/src/api/server/common.rst
index 04dfb96..a15f8c3 100644
--- a/src/api/server/common.rst
+++ b/src/api/server/common.rst
@@ -802,7 +802,7 @@ error.
:<header Accept: - :mimetype:`application/json`
:>header Content-Type: - :mimetype:`application/json`
:query number limit: How many results to return
- :query number skip: How many result to skip starting at the beggining,
+ :query number skip: How many result to skip starting at the beginning,
ordered by replication ID
:>json number offset: How many results were skipped
:>json number total_rows: Total number of replication jobs
@@ -909,7 +909,7 @@ error.
:<header Accept: - :mimetype:`application/json`
:>header Content-Type: - :mimetype:`application/json`
:query number limit: How many results to return
- :query number skip: How many result to skip starting at the beggining, if
+ :query number skip: How many result to skip starting at the beginning, if
ordered by document ID
:>json number offset: How many results were skipped
:>json number total_rows: Total number of replication documents.
@@ -1006,7 +1006,7 @@ error.
:<header Accept: - :mimetype:`application/json`
:>header Content-Type: - :mimetype:`application/json`
:query number limit: How many results to return
- :query number skip: How many result to skip starting at the beggining, if
+ :query number skip: How many result to skip starting at the beginning, if
ordered by document ID
:>json number offset: How many results were skipped
:>json number total_rows: Total number of replication documents.
diff --git a/src/cluster/databases.rst b/src/cluster/databases.rst
index 62edd3a..f008eb6 100644
--- a/src/cluster/databases.rst
+++ b/src/cluster/databases.rst
@@ -35,8 +35,8 @@ If you do not specify ``n`` and ``q`` the default will be used. The default is
.. _cluster/databases/delete:
-Deleteing a database
-====================
+Deleting a database
+===================
.. code-block:: bash
@@ -51,7 +51,7 @@ In BigCouch, the predecessor to CouchDB 2.0's clustering functionality, there
was the concept of zones. CouchDB 2.0 carries this forward with cluster
placement rules.
-First, each node must be labelled with a zone attribute. This defines which
+First, each node must be labeled with a zone attribute. This defines which
zone each node is in. You do this by editing the node's document in the
``/nodes`` database, which is accessed through the "back-door" (5986) port.
Add a key value pair of the form:
@@ -62,7 +62,7 @@ Add a key value pair of the form:
Do this for all of the nodes in your cluster.
-In your config file (local.ini or default.ini) on each node, define a
+In your config file (``local.ini`` or ``default.ini``) on each node, define a
consistent cluster-wide setting like:
.. code-block:: text
@@ -72,7 +72,7 @@ consistent cluster-wide setting like:
In this example, it will ensure that two replicas for a shard will be hosted
on nodes with the zone attribute set to ``metro-dc-a`` and one replica will
-be hosted on a new wiht the zone attribute set to ``metro-dc-b``.
+be hosted on a new with the zone attribute set to ``metro-dc-b``.
Note that you can also use this system to ensure certain nodes in the cluster
do not host *any* replicas for newly created databases, by giving them a zone
diff --git a/src/cluster/setup.rst b/src/cluster/setup.rst
index f8e238b..9750367 100644
--- a/src/cluster/setup.rst
+++ b/src/cluster/setup.rst
@@ -12,9 +12,9 @@
.. _cluster/setup:
-=====
-Setup
-=====
+======
+Set Up
+======
Everything you need to know to prepare the cluster for the installation of
CouchDB.
@@ -154,15 +154,14 @@ Setting up a cluster of Erlang applications correctly can be a daunting
task. Luckily, CouchDB 2.0 comes with a convenient Cluster Setup Wizard
as part of the Fauxton web administration interface.
-After installation and initial startup, visit Fauxton at
+After installation and initial start-up, visit Fauxton at
``http://127.0.0.1:5984/_utils#setup``. You will be asked to set up
CouchDB as a single-node instance or set up a cluster.
-When you click "setup cluster" you are asked for
-admin credentials again and then to add nodes by IP address. To get
-more nodes, go through the same install procedure on other machines.
-Be sure to specify the total number of nodes you expect to add to the
-cluster before adding nodes.
+When you click "setup cluster" you are asked for admin credentials again and
+then to add nodes by IP address. To get more nodes, go through the same install
+procedure on other machines. Be sure to specify the total number of nodes you
+expect to add to the cluster before adding nodes.
Before you can add nodes to form a cluster, you have to have them
listen on a public IP address and set up an admin user. Do this, once
@@ -186,20 +185,20 @@ your cluster.
Now your cluster is ready and available. You can send requests to any
one of the nodes and get to all the data.
-For a proper production setup, you'd now set up a HTTP proxy in front
+For a proper production setup, you'd now set up an HTTP proxy in front
of the nodes, that does load balancing. We recommend `HAProxy`_. See
our `example configuration for HAProxy`_. All you need is to adjust the
ip addresses and ports.
.. _cluster/setup/api:
-The Cluster Setup Api
-========================
+The Cluster Setup API
+=====================
If you would prefer to manually configure your CouchDB cluster, CouchDB exposes
-the ``_cluster_setup`` endpoint for that. After installation and initial setup.
-We can setup the cluster. On each node we need to run the following command to
-setup the node:
+the ``_cluster_setup`` endpoint for that. After installation and initial setup,
+we can set up the cluster. On each node we need to run the following command to
+set up the node:
.. code-block:: bash
@@ -209,9 +208,9 @@ After that we can join all the nodes together. Choose one node
as the "setup coordination node" to run all these commands on.
This is a "setup coordination node" that manages the setup and
requires all other nodes to be able to see it and vice versa.
-Setup will not work with unavailable nodes.
+Set up will not work with unavailable nodes.
The notion of "setup coordination node" will be gone once the setup is finished.
-From then onwards the cluster will no longer have a "setup coordination node".
+From then on, the cluster will no longer have a "setup coordination node".
To add a node run these two commands:
.. code-block:: bash
@@ -228,7 +227,7 @@ following command to complete the setup and add the missing databases:
curl -X POST -H "Content-Type: application/json" http://admin:password@127.0.0.1:5984/_cluster_setup -d '{"action": "finish_cluster"}'
-You CouchDB cluster is now setup.
+You CouchDB cluster is now set up.
.. _HAProxy: http://haproxy.org/
.. _example configuration for HAProxy: https://github.com/apache/couchdb/blob/master/rel/haproxy.cfg
diff --git a/src/cluster/sharding.rst b/src/cluster/sharding.rst
index 98d946d..b2ef4ea 100644
--- a/src/cluster/sharding.rst
+++ b/src/cluster/sharding.rst
@@ -267,7 +267,7 @@ time you move a shard. As this can take quite some time, it is not recommended.
Reshard? No, Preshard!
======================
-Reshard? Nope. It can not be done. So do not create databases with too few
+Reshard? Nope. It cannot be done. So do not create databases with too few
shards.
If you can not scale out more because you set the number of shards too low, then
diff --git a/src/cluster/theory.rst b/src/cluster/theory.rst
index b93c610..431324a 100644
--- a/src/cluster/theory.rst
+++ b/src/cluster/theory.rst
@@ -55,7 +55,7 @@ comes crashing down.
Computers go down and sysadmins pull out network cables in a furious rage from
time to time, so using ``n<2`` is asking for downtime. Having too high a value
-of ``n`` adds servers and complexity without any real benefit. The sweetspot is
+of ``n`` adds servers and complexity without any real benefit. The sweet spot is
at ``n=3``.
Say that we have a database with 3 replicas and 4 shards. That would give us a
diff --git a/src/config/auth.rst b/src/config/auth.rst
index 6d5322e..8a22a2a 100644
--- a/src/config/auth.rst
+++ b/src/config/auth.rst
@@ -183,7 +183,7 @@ Authentication Configuration
[couch_httpd_auth]
max_iterations = 100000
- .. config:option:: proxy_use_secret :: Force proxy auth use secret token
+ .. config:option:: proxy_use_secret :: Force proxy auth to use secret token
When this option is set to ``true``, the
:option:`couch_httpd_auth/secret` option is required for
diff --git a/src/config/http.rst b/src/config/http.rst
index 1330da2..9498d27 100644
--- a/src/config/http.rst
+++ b/src/config/http.rst
@@ -115,7 +115,7 @@ HTTP Server Options
[httpd]
redirect_vhost_handler = {Module, Fun}
- The specified function take 2 arguments: the Mochiweb request object
+ The specified function take 2 arguments: the MochiWeb request object
and the target path.
.. config:option:: server_options :: MochiWeb Server Options
@@ -199,7 +199,7 @@ HTTP Server Options
.. config:option:: WWW-Authenticate :: Force basic auth
- Set this option to trigger basic-auth popup on unauthorized requests::
+ Set this option to trigger basic-auth pop-up on unauthorized requests::
[httpd]
WWW-Authenticate = Basic realm="Welcome to the Couch!"
@@ -241,7 +241,7 @@ HTTP Server Options
.. warning::
Removing the Server header from the settings will mean that
the CouchDB server header is replaced with the
- Mochiweb server header.
+ MochiWeb server header.
.. config:option:: authentication_handlers :: Authentication handlers
@@ -370,7 +370,7 @@ Secure Socket Level Options
.. config:option:: password :: Certificate key password
- String containing the user's password. Only used if the private keyfile
+ String containing the user's password. Only used if the private key file
is password protected::
[ssl]
diff --git a/src/config/intro.rst b/src/config/intro.rst
index aad6e6a..21f0d6d 100644
--- a/src/config/intro.rst
+++ b/src/config/intro.rst
@@ -28,7 +28,7 @@ in the following order:
#. ``etc/local.ini``
#. ``etc/local.d/*.ini``
-All paths are specified relative to the couchdb installation directory:
+All paths are specified relative to the CouchDB installation directory:
``/opt/couchdb`` recommended on UNIX-like systems, ``C:\CouchDB`` recommended
on Windows systems, and a combination of two directories on macOS:
``Applications/Apache CouchDB.app/Contents/Resources/couchdbx-core/etc`` for
diff --git a/src/config/logging.rst b/src/config/logging.rst
index 8aa9c35..4b8900d 100644
--- a/src/config/logging.rst
+++ b/src/config/logging.rst
@@ -63,7 +63,7 @@ Logging options
.. config:option:: write_delay
- Specifies the wait in milliseconds before commiting logs to disk, to
+ Specifies the wait in milliseconds before committing logs to disk, to
enable delayed log writes. Only used by the ``file``
:option:`writer <log/writer>`::
diff --git a/src/config/query-servers.rst b/src/config/query-servers.rst
index 62fd705..97191f5 100644
--- a/src/config/query-servers.rst
+++ b/src/config/query-servers.rst
@@ -140,7 +140,7 @@ Native Erlang Query Server
Unlike the JavaScript query server, the Erlang one does not runs in a
sandbox mode. This means that Erlang code has full access to your OS,
- filesystem and network, which may lead to security issues. While Erlang
+ file system and network, which may lead to security issues. While Erlang
functions are faster than JavaScript ones, you need to be careful
about running them, especially if they were written by someone else.
diff --git a/src/config/replicator.rst b/src/config/replicator.rst
index ec8ba5c..d259fed 100644
--- a/src/config/replicator.rst
+++ b/src/config/replicator.rst
@@ -63,7 +63,7 @@ Replicator Database Configuration
.. versionadded:: 2.1
When set to ``true`` replicator will update replication document with
- error and triggered states. This approximates pre 2.1 replicator
+ error and triggered states. This approximates pre-2.1 replicator
behavior::
[replicator]
@@ -107,7 +107,7 @@ Replicator Database Configuration
If a request fails, the replicator will retry it up to N times. The
default value for N is 5 (before version 2.1.1 it was 10). The requests
- are retried with a doubling exponenital backoff starting at 0.25
+ are retried with a doubling exponential backoff starting at 0.25
seconds. So by default requests would be retried in 0.25, 0.5, 1, 2, 4
second intervals. When number of retires is exhausted, the whole
replication job is stopped and will retry again later::
@@ -183,8 +183,8 @@ Replicator Database Configuration
.. config:option:: password
- String containing the user's password. Only used if the private keyfile
- is password protected::
+ String containing the user's password. Only used if the private key file
+ is password protected::
[replicator]
password = somepassword
diff --git a/src/config/services.rst b/src/config/services.rst
index 983c7f8..90f48f2 100644
--- a/src/config/services.rst
+++ b/src/config/services.rst
@@ -55,7 +55,7 @@ CouchDB Daemonized Mini Apps
.. config:option:: httpsd
- Provides :ref:`SSL support <config/ssl>`. The default ssl port CouchDB
+ Provides :ref:`SSL support <config/ssl>`. The default SSL port CouchDB
listens on is `6984`::
[daemons]
diff --git a/src/contributing.rst b/src/contributing.rst
index 4fd7722..94e04b2 100644
--- a/src/contributing.rst
+++ b/src/contributing.rst
@@ -79,10 +79,10 @@ http://docs.couchdb.org/en/latest/json-structure.html -- we are in luck, under
`share/doc/src` we find the file `json-structure.rst`. That looks promising.
`.rst` stands for ReStructured Text (see
http://thomas-cokelaer.info/tutorials/sphinx/rest_syntax.html
-for a markup reference), which is an ascii format for writing
+for a markup reference), which is an ASCII format for writing
documents, documentation in this case. Let's have a look and open it.
-We see ascii tables with some additional formatting, all looking like the
+We see ASCII tables with some additional formatting, all looking like the
final HTML. So far so easy. For now, let's just add to the bottom of this. We
can worry about organising this better later.
@@ -188,7 +188,7 @@ The guidelines are in descending priority.
#. Line ending
* All lines end with ``\n``.
- * No trailing whitespaces.
+ * No trailing whitespace.
#. Line length
diff --git a/src/ddocs/ddocs.rst b/src/ddocs/ddocs.rst
index 117b0b5..b12a94e 100644
--- a/src/ddocs/ddocs.rst
+++ b/src/ddocs/ddocs.rst
@@ -113,8 +113,8 @@ single value - which could be an array or similar object.
.. _reducefun/builtin:
-Builtin Reduce Functions
-^^^^^^^^^^^^^^^^^^^^^^^^
+Built-in Reduce Functions
+^^^^^^^^^^^^^^^^^^^^^^^^^
Additionally, CouchDB has three built-in reduce functions. These are implemented
in Erlang and run inside CouchDB, so they are much faster than the equivalent
diff --git a/src/ddocs/views/collation.rst b/src/ddocs/views/collation.rst
index d080473..cc6071c 100644
--- a/src/ddocs/views/collation.rst
+++ b/src/ddocs/views/collation.rst
@@ -92,7 +92,7 @@ String Ranges
=============
If you need start and end keys that encompass every string with a given prefix,
-it is better to use a high value unicode character, than to use a ``'ZZZZ'``
+it is better to use a high value Unicode character, than to use a ``'ZZZZ'``
suffix.
That is, rather than::
diff --git a/src/ddocs/views/intro.rst b/src/ddocs/views/intro.rst
index 6ac36cd..eb759b0 100644
--- a/src/ddocs/views/intro.rst
+++ b/src/ddocs/views/intro.rst
@@ -418,7 +418,7 @@ on the ``rereduce`` parameter:
}
.. note::
- The JavaScript function above could be effectively replaced by the builtin
+ The JavaScript function above could be effectively replaced by the built-in
``_count``.
.. figure:: ../../../images/views-intro-01.png
diff --git a/src/ddocs/views/nosql.rst b/src/ddocs/views/nosql.rst
index 6dfd4c2..ceff7ad 100644
--- a/src/ddocs/views/nosql.rst
+++ b/src/ddocs/views/nosql.rst
@@ -314,7 +314,7 @@ Here’s an alternate, more idiomatic JavaScript version:
}
.. note::
- Don't miss effective builtin :ref:`reduce functions <reducefun>` like
+ Don't miss effective built-in :ref:`reduce functions <reducefun>` like
``_sum`` and ``_count``
This reduce function takes two arguments: a list of keys and a list of values.
diff --git a/src/install/freebsd.rst b/src/install/freebsd.rst
index 88c6728..028d43b 100644
--- a/src/install/freebsd.rst
+++ b/src/install/freebsd.rst
@@ -55,7 +55,7 @@ Post install
**Be sure to complete the** :ref:`First-time Setup <install/setup>` **steps for
a single node or clustered installation.**
-In case the install script fails to install a noninteractive user "couchdb" to
+In case the install script fails to install a non-interactive user "couchdb" to
be used for the database, the user needs to be created manually:
I used the ``pw`` command to add a user "couchdb" in group "couchdb":
diff --git a/src/install/mac.rst b/src/install/mac.rst
index 9ab339c..69440c8 100644
--- a/src/install/mac.rst
+++ b/src/install/mac.rst
@@ -66,7 +66,7 @@ Running as a Daemon
CouchDB itself no longer ships with any daemonization scripts.
-The couchdb team recommends `runit <http://smarden.org/runit/>`_ to
+The CouchDB team recommends `runit <http://smarden.org/runit/>`_ to
run CouchDB persistently and reliably. Configuration of runit is
straightforward; if you have questions, reach out to the CouchDB
user mailing list.
diff --git a/src/install/snap.rst b/src/install/snap.rst
index ecd4a8c..f932af1 100644
--- a/src/install/snap.rst
+++ b/src/install/snap.rst
@@ -23,7 +23,7 @@ Ubuntu snapcraft repository under the name ``couchdb``. Only snaps built
from official stable CouchDB releases (``2.0``, ``2.1``, etc.) are available
through this channel.
-After `installing snapd`_, the couchdb snap can be installed via::
+After `installing snapd`_, the CouchDB snap can be installed via::
$ sudo snap install couchdb
diff --git a/src/install/troubleshooting.rst b/src/install/troubleshooting.rst
index fdf40ea..58fe5a1 100644
--- a/src/install/troubleshooting.rst
+++ b/src/install/troubleshooting.rst
@@ -83,9 +83,9 @@ things:
<<"[1,2,3,4,5]">>
4> q().
-- At this point the only remaining dependency is your systems' unicode support
+- At this point the only remaining dependency is your system's Unicode support
library, ICU, and the Spidermonkey Javascript VM from Mozilla. Make sure that
- your ``LD_LIBRARY_PATH`` or similar for non-Linux systems
+ your ``LD_LIBRARY_PATH`` or equivalent for non-Linux systems
(``DYLD_LIBRARY_PATH`` on macOS) makes these available to CouchDB.
Linux example running as normal user:
@@ -125,7 +125,7 @@ correct. Please recheck your build dependencies and try again.
… OS Process Error … {os_process_error,{exit_status,139}}
this is caused by the fact that SELinux blocks access to certain areas of
-the filesystem. You must re-configure SELinux, or you can fully disable
+the file system. You must re-configure SELinux, or you can fully disable
SELinux using the command:
.. code-block:: text
@@ -195,7 +195,7 @@ Lots of memory being used on startup
Is your CouchDB using a lot of memory (several hundred MB) on startup? This one
seems to especially affect Dreamhost installs. It's really an issue with the
Erlang VM pre-allocating data structures when ulimit is very large or
-unlimited. A detailed dicussion can be found on the erlang-questions list,
+unlimited. A detailed discussion can be found on the erlang-questions list,
but the short answer is that you should decrease ``ulimit -n`` or define
``ERL_MAX_PORTS`` to something reasonable like 1024.
@@ -266,7 +266,7 @@ The function needs to return a value:
erlang stack trace contains ``bad_utf8_character_code``
-------------------------------------------------------
-CouchDB 1.1.1 and later contains stricter handling of UTF8 encoding. If you are
+CouchDB 1.1.1 and later contain stricter handling of UTF8 encoding. If you are
replicating from older versions to newer versions, then this error may occur
during replication.
diff --git a/src/install/upgrading.rst b/src/install/upgrading.rst
index 34e3c9b..60e16f2 100644
--- a/src/install/upgrading.rst
+++ b/src/install/upgrading.rst
@@ -37,7 +37,7 @@ Overview
--------
couchup makes it easy to migrate your CouchDB 1.x databases to CouchDB
-2.x by providing useful 4 sub-commands:
+2.x by providing 4 useful sub-commands:
* ``list`` - lists all CouchDB 1.x databases
* ``replicate`` - replicates one or more 1.x databases to CouchDB 2.x
diff --git a/src/intro/security.rst b/src/intro/security.rst
index 011b381..5cbf7f6 100644
--- a/src/intro/security.rst
+++ b/src/intro/security.rst
@@ -289,7 +289,7 @@ several *mandatory* fields, that CouchDB needs for authentication:
- **name** (*string*): User's name aka login. **Immutable** e.g. you cannot
rename an existing user - you have to create new one
- **roles** (*array* of *string*): List of user roles. CouchDB doesn't provide
- any builtin roles, so you're free to define your own depending on your needs.
+ any built-in roles, so you're free to define your own depending on your needs.
However, you cannot set system roles like ``_admin`` there. Also, only
administrators may assign roles to users - by default all users have no roles
- **password_sha** (*string*): Hashed password with salt. Used for ``simple``
diff --git a/src/intro/why.rst b/src/intro/why.rst
index d04d1b5..aa4b683 100644
--- a/src/intro/why.rst
+++ b/src/intro/why.rst
@@ -282,7 +282,7 @@ CouchDB can solve this scenario as well, and this is where scaling is
important again. This time it is scaling down. Imagine CouchDB installed on
phones and other mobile devices that can synchronize data with centrally
hosted CouchDBs when they are on a network. The synchronization is not bound
-by user interface constraints like subsecond response times. It is easier to
+by user interface constraints like sub-second response times. It is easier to
tune for high bandwidth and higher latency than for low bandwidth and very
low latency. Mobile applications can then use the local CouchDB to fetch
data, and since no remote networking is required for that,
diff --git a/src/json-structure.rst b/src/json-structure.rst
index 89fddea..2d8e5a1 100644
--- a/src/json-structure.rst
+++ b/src/json-structure.rst
@@ -527,7 +527,7 @@ Response object
The ``body``, ``base64`` and ``json`` object keys are overlapping each other
where the last one wins. Since most realizations of key-value objects do
not preserve the key order or if they are mixed, confusing situations can
- occure. Try to use only one of them.
+ occur. Try to use only one of them.
.. note::
Any custom property makes CouchDB raise an internal exception. Furthermore,
diff --git a/src/maintenance/performance.rst b/src/maintenance/performance.rst
index 9d6bbe7..82a36dd 100644
--- a/src/maintenance/performance.rst
+++ b/src/maintenance/performance.rst
@@ -193,7 +193,7 @@ involved in assembling JSON, doing the networking and decoding JSON.
As of CouchDB 1.1.0, users often report lower write performance of documents
compared to older releases. The main reason is that this release ships with
-the more recent version of the HTTP server library Mochiweb, which by default
+the more recent version of the HTTP server library MochiWeb, which by default
sets the TCP socket option `SO_NODELAY`_ to false. This means that small data
sent to the TCP socket, like the reply to a document write request (or reading
a very small document), will not be sent immediately to the network - TCP will
@@ -226,7 +226,7 @@ non-deleted documents, can affect view build times, :method:`PUT` and
:method:`DELETE` requests time and size of database on disk, since they
increase the size of the B+Tree's. You can see the number of deleted documents
in :get:`database information </{db}>`. If your use case creates lots of
-deleted documents (for example, if you are storing short-term data like logfile
+deleted documents (for example, if you are storing short-term data like log
entries, message queues, etc), you might want to periodically switch to a new
database and delete the old one (once the entries in it have all expired).
@@ -275,8 +275,8 @@ use any available replica by specifying ``stable=false&update=false`` instead of
View information isn't replicated - it is rebuilt on each database so you
can't do the view generation on a separate sever.
-Builtin Reduce Functions
-------------------------
+Built-In Reduce Functions
+-------------------------
If you’re using a very simple view function that only performs a sum or count
reduction, you can call native Erlang implementations of them by simply
diff --git a/src/query-server/javascript.rst b/src/query-server/javascript.rst
index 85504d9..ca87688 100644
--- a/src/query-server/javascript.rst
+++ b/src/query-server/javascript.rst
@@ -219,7 +219,7 @@ modules and functions:
Encodes `obj` to JSON string. This is an alias for the ``JSON.stringify``
method.
- :param obj: JSON encodable object
+ :param obj: JSON-encodable object
:return: JSON string
.. _commonjs:
diff --git a/src/replication/conflicts.rst b/src/replication/conflicts.rst
index 9b5d489..7b59cfa 100644
--- a/src/replication/conflicts.rst
+++ b/src/replication/conflicts.rst
@@ -74,7 +74,7 @@ The answer is simple: both versions exist on both sides!
| v2b | | v2b |
+---------+ +---------+
-After all, this is not a filesystem, so there's no restriction that only one
+After all, this is not a file system, so there's no restriction that only one
document can exist with the name /db/bob. These are just "conflicting" revisions
under the same name.
@@ -514,7 +514,7 @@ file so that it knows whether a file has changed since the last successful
replication.
In our example it has changed on both sides. Only one file called `bob.vcf`
-can exist within the filesystem. Unison solves the problem by simply ducking
+can exist within the file system. Unison solves the problem by simply ducking
out: the user can choose to replace the remote version with the local version,
or vice versa (both of which would lose data), but the default action is to
leave both sides unchanged.
@@ -697,11 +697,11 @@ useful characteristics:
the new data, plus the revision ID of the previous.
#. In addition to application data (``{"name": "Jason", "awesome": true}``),
- every record stores the evolutionary timeline of all previous revision IDs
+ every record stores the evolutionary time line of all previous revision IDs
leading up to itself.
- Exercise: Take a moment of quiet reflection. Consider any two different
- records, A and B. If A's revision ID appears in B's timeline, then B
+ records, A and B. If A's revision ID appears in B's time line, then B
definitely evolved from A. Now consider Git's fast-forward merges.
Do you hear that? That is the sound of your mind being blown.
@@ -709,14 +709,14 @@ useful characteristics:
children. CouchDB has that too.
- Exercise: Compare two different records, A and B. A's revision ID does not
- appear in B's timeline; however, one revision ID, C, is in both A's and B's
- timeline. Thus A didn't evolve from B. B didn't evolve from A. But rather,
- A and B have a common ancestor C. In Git, that is a "fork." In CouchDB,
- it's a "conflict."
+ appear in B's time line; however, one revision ID, C, is in both A's and
+ B's time line. Thus A didn't evolve from B. B didn't evolve from A. But
+ rather, A and B have a common ancestor C. In Git, that is a "fork." In
+ CouchDB, it's a "conflict."
- - In Git, if both children go on to develop their timelines independently,
+ - In Git, if both children go on to develop their time lines independently,
that's cool. Forks totally support that.
- - In CouchDB, if both children go on to develop their timelines
+ - In CouchDB, if both children go on to develop their time lines
independently, that cool too. Conflicts totally support that.
- **Fun fact 3**: CouchDB "conflicts" do not correspond to Git "conflicts."
A Couch conflict is a divergent revision history, what Git calls a "fork."
@@ -727,15 +727,15 @@ useful characteristics:
has that too.
- **In the data model, there is no merge.** The client simply marks one
- timeline as deleted and continues to work with the only extant timeline.
+ time line as deleted and continues to work with the only extant time line.
- **In the application, it feels like a merge.** Typically, the client merges
- the *data* from each timeline in an application-specific way.
- Then it writes the new data to the timeline. In Git, this is like copying
- and pasting the changes from branch A into branch B, then commiting to
+ the *data* from each time line in an application-specific way.
+ Then it writes the new data to the time line. In Git, this is like copying
+ and pasting the changes from branch A into branch B, then committing to
branch B and deleting branch A. The data was merged, but there was no
`git merge`.
- - These behaviors are different because, in Git, the timeline itself is
- important; but in CouchDB, the data is important and the timeline is
+ - These behaviors are different because, in Git, the time line itself is
+ important; but in CouchDB, the data is important and the time line is
incidental—it's just there to support replication. That is one reason why
CouchDB's built-in revisioning is inappropriate for storing revision data
like a wiki page.
diff --git a/src/replication/intro.rst b/src/replication/intro.rst
index 8890af4..98f97b0 100644
--- a/src/replication/intro.rst
+++ b/src/replication/intro.rst
@@ -18,7 +18,7 @@ Introduction to Replication
One of CouchDB's strengths is the ability to synchronize two copies of the same
database. This enables users to distribute data across several nodes or
-datacenters, but also to move data more closely to clients.
+data centers, but also to move data more closely to clients.
Replication involves a source and a destination database, which can be on the
same or on different CouchDB instances. The aim of the replication is that at
@@ -53,7 +53,7 @@ on the source will also be deleted on the target.
A replication task will finish once it reaches the end of the changes feed. If
its `continuous` property is set to true, it will wait for new changes to
-appear until the task is cancelled. Replication tasks also create checkpoint
+appear until the task is canceled. Replication tasks also create checkpoint
documents on the destination to ensure that a restarted task can continue from
where it stopped, for example after it has crashed.
diff --git a/src/replication/protocol.rst b/src/replication/protocol.rst
index e98ab14..2dc3041 100644
--- a/src/replication/protocol.rst
+++ b/src/replication/protocol.rst
@@ -616,7 +616,7 @@ The Replication Log SHOULD contain the following fields:
- **docs_read** (*number*): Number of read documents
- **docs_written** (*number*): Number of written documents
- **end_last_seq** (*number*): Last processed Update Sequence ID
- - **end_time** (*string*): Replication completion datetime in :rfc:`5322`
+ - **end_time** (*string*): Replication completion timestamp in :rfc:`5322`
format
- **missing_checked** (*number*): Number of checked revisions on Source
- **missing_found** (*number*): Number of missing revisions found on Target
@@ -624,7 +624,7 @@ The Replication Log SHOULD contain the following fields:
- **session_id** (*string*): Unique session ID. Commonly, a random UUID value
is used. **Required**
- **start_last_seq** (*number*): Start update Sequence ID
- - **start_time** (*string*): Replication start datetime in :rfc:`5322` format
+ - **start_time** (*string*): Replication start timestamp in :rfc:`5322` format
- **replication_id_version** (*number*): Replication protocol version. Defines
Replication ID calculation algorithm, HTTP API calls and the others
diff --git a/src/replication/replicator.rst b/src/replication/replicator.rst
index 10079b4..10139bd 100644
--- a/src/replication/replicator.rst
+++ b/src/replication/replicator.rst
@@ -132,7 +132,7 @@ start it would not appear here, only in ``_scheduler/docs``.
If there is an error, for example if the source database is missing, the
replication job will crash and retry after a wait period. Each
-sucesssive crash will result in a longer waiting period.
+successive crash will result in a longer waiting period.
For example, POST-ing this document
@@ -257,7 +257,7 @@ Replication Scheduler
Once replication jobs are created they are managed by the scheduler. The
scheduler is the replication component which periodically stops some
-jobs and starts others. This behavior makes it posssible to have a
+jobs and starts others. This behavior makes it possible to have a
larger number of jobs than the cluster could run simultaneously.
Replication jobs which keep failing will be penalized and forced to
wait. The wait time increases exponentially with each consecutive
@@ -368,7 +368,7 @@ retried and don't consume memory or CPU resources.
* ``Completed``: This is a terminal, successful state for
non-continuous replications. Once in this state the replication is
"forgotten" by the scheduler and it doesn't consume any more CPU or
- memory resorces. Continuous replication jobs will never reach this
+ memory resources. Continuous replication jobs will never reach this
state.
.. _Normal vs Continuous Replications:
diff --git a/src/whatsnew/1.0.rst b/src/whatsnew/1.0.rst
index 9e1b7b4..5355d9a 100644
--- a/src/whatsnew/1.0.rst
+++ b/src/whatsnew/1.0.rst
@@ -177,7 +177,7 @@ Storage System
* Fix leaking file handles after compacting databases and views.
* Fix databases forgetting their validation function after compaction.
* Fix occasional timeout errors after successfully compacting large databases.
-* Fix ocassional error when writing to a database that has just been compacted.
+* Fix occasional error when writing to a database that has just been compacted.
* Fix occasional timeout errors on systems with slow or heavily loaded IO.
* Fix for OOME when compactions include documents with many conflicts.
* Fix for missing attachment compression when MIME types included parameters.
diff --git a/src/whatsnew/1.1.rst b/src/whatsnew/1.1.rst
index f6ad383..696bb8c 100644
--- a/src/whatsnew/1.1.rst
+++ b/src/whatsnew/1.1.rst
@@ -156,7 +156,7 @@ Storage System
URL Rewriter & Vhosts
---------------------
-* Fix for variable substituion
+* Fix for variable substitution
View Server
-----------
diff --git a/src/whatsnew/1.3.rst b/src/whatsnew/1.3.rst
index 61931fc..589dfdb 100644
--- a/src/whatsnew/1.3.rst
+++ b/src/whatsnew/1.3.rst
@@ -100,7 +100,7 @@ Futon
* :issue:`627`: Support all timezones. :commit:`b1a049bb`
* :issue:`1383`: Futon view editor won't allow you to save original view after
saving a revision. :commit:`ce48342`
-* :issue:`1470`: Futon raises popup on attempt to navigate to missed/deleted
+* :issue:`1470`: Futon raises pop-up on attempt to navigate to missed/deleted
document. :commit:`5da40eef`
* :issue:`1473`, :issue:`1472`: Disable buttons for actions that the user
doesn't have permissions to. :commit:`7156254d`
@@ -235,19 +235,19 @@ UUID Algorithms
Query and View Server
---------------------
-* :issue:`111`: Improve the errors reported by the javascript view server
+* :issue:`111`: Improve the errors reported by the JavaScript view server
to provide a more friendly error report when something goes wrong.
:commit:`0c619ed`
* :issue:`410`: More graceful error handling for JavaScript validate_doc_update
functions.
-* :issue:`1372`: `_stats` builtin reduce function no longer produces error for
+* :issue:`1372`: `_stats` built-in reduce function no longer produces error for
empty view result.
* :issue:`1444`: Fix missed_named_view error that occurs on existed design
documents and views. :commit:`b59ac98b`
* :issue:`1445`: CouchDB tries no more to delete view file if it couldn't open
it, even if the error is `emfile`.
* :issue:`1483`: Update handlers requires valid doc ids. :commit:`72ea7e38`
-* :issue:`1491`: Clenaup view tables. :commit:`c37204b7`
+* :issue:`1491`: Clean up view tables. :commit:`c37204b7`
* Deprecate E4X support, :commit:`cdfdda2314`
Windows
diff --git a/src/whatsnew/2.0.rst b/src/whatsnew/2.0.rst
index 1f70841..8437b5c 100644
--- a/src/whatsnew/2.0.rst
+++ b/src/whatsnew/2.0.rst
@@ -147,5 +147,5 @@ The following changes in 2.0 represent a significant deviation from
CouchDB 1.x and may alter behaviour of systems designed to work with
older versions of CouchDB:
-* :ghissue:`620`: ``POST /dbname`` no longer returns an ETag reponse header,
+* :ghissue:`620`: ``POST /dbname`` no longer returns an ETag response header,
in compliance with RFC 7231, Section 7.2.
--
To stop receiving notification emails like this one, please contact
"commits@couchdb.apache.org" <co...@couchdb.apache.org>.