merge: minor corrections

Author: Sam Kleinman

source/administration/replica-sets.txt

@@ -54,7 +54,7 @@ configurations.
 
 .. warning::
 
-   The :method:`rs.reconfig()` shell command can force the current
+   The :method:`rs.reconfig()` shell method can force the current
    primary to step down, which causes an :ref:`election <replica-set-elections>`. When the primary
    steps down, the :program:`mongod` closes all client
    connections. While, this typically takes 10-20 seconds, attempt to
@@ -102,7 +102,7 @@ replica set. Use the following sequence of operations in the
    cfg.members[3].priority = 2
    rs.reconfig(cfg)
 
-This configures the set, with the following priority settings: 
+This configures the set, with the following priority settings:
 
 - The first (i.e. )Member ``0`` to a priority of ``0`` so that it can never become :term:`primary`.
 
@@ -169,7 +169,7 @@ not advertise the hidden member in the :dbcommand:`isMaster` or
    that *can* become :term:`primary`. In the above example, if you
    issue the :method:`rs.reconfig()` operation to a member with a
    :data:`priority <members.[n].priority>` of ``0`` the operation will
-   fail. 
+   fail.
 
 .. note::
 
@@ -722,7 +722,7 @@ shell connected to the replica set's :term:`primary`. For descriptions
 of the information displayed by :method:`rs.status()`, see
 :doc:`/reference/replica-status`.
 
-.. note:: 
+.. note::
 
    The :method:`rs.status()` method is a wrapper that runs the
    :dbcommand:`replSetGetStatus` database command.
@@ -758,7 +758,7 @@ To check the current length of replication lag:
          syncedTo: Tue Oct 02 2012 11:33:40 GMT-0400 (EDT)
              = 7475 secs ago (2.08hrs)
 
-  .. note:: 
+  .. note::
 
      The :method:`rs.status()` method is a wrapper around the
      :dbcommand:`replSetGetStatus` database command.
@@ -962,7 +962,7 @@ operational errors:
 In many senses, :ref:`rollbacks <replica-set-rollbacks>` represent a
 graceful recovery from an impossible failover and recovery situation.
 
-Rollbacks occur when 
+Rollbacks occur when
 a primary accepts writes that other members of
 the set do not successfully replicate before the primary steps
 down. When the former primary begins replicating again it performs a

source/administration/sharding-architectures.txt

@@ -106,7 +106,7 @@ created subsequently, may reside on any shard in the cluster.
 .. [#sharding-databases] As you configure sharding, you will use the
    :dbcommand:`enableSharding` command to enable sharding for a
    database. This simply makes it possible to use the
-   :dbcommand:`shardCollection` on a collection within that database.
+   :dbcommand:`shardCollection` command on a collection within that database.
 
 .. [#overloaded-primary-term] The term "primary" in the context of
    databases and sharding, has nothing to do with the term

source/administration/sharding.txt

@@ -236,7 +236,7 @@ procedure:
    .. optional::
 
       You may specify a "name" as an argument to the
-      :dbcommand:`addShard`, as follows:
+      :dbcommand:`addShard` command, as follows:
 
       .. code-block:: javascript
 
@@ -323,7 +323,7 @@ The procedure to remove a shard is as follows:
 
 #. View progress of the migration.
 
-   You can run the :dbcommand:`removeShard` again at any stage of the
+   You can run the :dbcommand:`removeShard` command again at any stage of the
    process to view the progress of the migration, as follows:
 
    .. code-block:: javascript
@@ -360,7 +360,7 @@ The procedure to remove a shard is as follows:
 
    .. warning::
 
-      Do not run the :dbcommand:`movePrimary` until you have *finished*
+      Do not run the :dbcommand:`movePrimary` command until you have *finished*
       draining the shard.
 
    The command will not return until MongoDB completes moving all

source/core/sharding-internals.txt

@@ -267,7 +267,7 @@ Shard Key Indexes
 All sharded collections **must** have an index that starts with the
 :term:`shard key`. If you shard a collection that does not yet contain
 documents and *without* such an index, the :dbcommand:`shardCollection`
-will create an index on the shard key. If the collection already
+command will create an index on the shard key. If the collection already
 contains documents, you must create an appropriate index before using
 :dbcommand:`shardCollection`.
 

source/reference/collection-statistics.txt

@@ -48,7 +48,7 @@ Or:
 Example Document
 ----------------
 
-The output of :method:`db.collection.stats()` resembles the following: 
+The output of :method:`db.collection.stats()` resembles the following:
 
 .. code-block:: javascript
 
@@ -115,13 +115,13 @@ Fields
 
    The number of indexes on the collection. All collections have at
    least one index on the :term:`_id` field.
-   
+
    .. versionchanged:: 2.2
       Before 2.2, capped collections did not necessarily have an
       index on the ``_id`` field, and some capped collections created
       with pre-2.2 versions of :program:`mongod` may not have an
       ``_id`` index.
-      
+
 
 .. stats:: lastExtentSize
 
@@ -161,7 +161,7 @@ Fields
    Reports the flags on this collection set by the user. In version
    2.2 the only user flag is ``usePowerOf2Sizes``.
 
-   See :dbcommand:`collMod` for more information on setting user
+   See the :dbcommand:`collMod` command for more information on setting user
    flags and :ref:`usePowerOf2Sizes <usePowerOf2Sizes>`.
 
 .. stats:: totalIndexSize

source/reference/command/reIndex.txt

@@ -14,9 +14,9 @@ reIndex
       { reIndex: "collection" }
 
    Normally, MongoDB compacts indexes during routine updates. For most
-   users, the :dbcommand:`reIndex` is unnecessary. However, it may be worth
-   running if the collection size has changed significantly or if the
-   indexes are consuming a disproportionate amount of disk space.
+   users, the :dbcommand:`reIndex` command is unnecessary. However, it
+   may be worth running if the collection size has changed significantly
+   or if the indexes are consuming a disproportionate amount of disk space.
 
    Note that the :dbcommand:`reIndex` command will block the server against
    writes and may take a long time for large collections.

source/reference/command/renameCollection.txt

@@ -20,7 +20,7 @@ renameCollection
    The ``dropTarget`` argument is optional.
 
    If you specify a collection to the ``to`` argument in a different database, the
-   :dbcommand:`renameCollection` will copy the collection to the new
+   :dbcommand:`renameCollection` command will copy the collection to the new
    database and then drop the source collection.
 
    :param source-namespace:

source/reference/mongod.txt

@@ -54,8 +54,8 @@ Options
 .. option:: --quiet
 
    Runs the :program:`mongod` instance in a quiet mode that attempts to limit
-   the amount of output. This option suppresses: 
-   
+   the amount of output. This option suppresses:
+
    - output from :term:`database commands <database command>`,
      including :dbcommand:`drop`, :dbcommand:`dropIndexes`,
      :dbcommand:`diagLogging`, :dbcommand:`validate`, and
@@ -353,7 +353,7 @@ Options
 .. option:: --repair
 
    Runs a repair routine on all databases. This is equivalent
-   to shutting down and running :dbcommand:`repairDatabase` database
+   to shutting down and running the :dbcommand:`repairDatabase` database
    command on all databases.
 
    .. include:: /includes/warning-repair.rst
@@ -385,7 +385,7 @@ Options
    option. The database logs all slow queries to the log, even when
    the profiler is not turned on. When the database profiler is on,
    :program:`mongod` the profiler writes to the ``system.profile``
-   collection. See :dbcommand:`profile` for more information on the
+   collection. See the :dbcommand:`profile` command for more information on the
    database profiler.
 
 .. option:: --smallfiles
@@ -583,9 +583,9 @@ Sharding Cluster Options
 .. option:: --noMoveParanoia
 
    Disables a "paranoid mode" for data writes for chunk migration
-   operation. See the :ref:`chunk migration
-   <sharding-chunk-migration>` and :dbcommand:`moveChunk` command
-   documentation for more information.
+   operation. See the
+   :ref:`chunk migration <sharding-chunk-migration>`
+   and :dbcommand:`moveChunk` command documentation for more information.
 
    By default :program:`mongod` will save copies of migrated chunks on
    the "from" server during migrations as "paranoid mode." Setting

source/reference/replica-configuration.txt

@@ -383,7 +383,7 @@ use the following form:
 
 .. note::
 
-   The :method:`rs.reconfig()` shell command can force the current
+   The :method:`rs.reconfig()` shell method can force the current
    primary to step down and causes an election in some
    situations. When the primary steps down, all clients will
    disconnect. This is by design. While this typically takes 10-20

source/tutorial/deploy-geographically-distributed-replica-set.txt

@@ -215,7 +215,7 @@ To deploy a geographically distributed three-member set:
 
       .. note::
 
-         In some situations, the :method:`rs.reconfig()` shell command
+         In some situations, the :method:`rs.reconfig()` shell method
          can force the current primary to step down and causes an
          election. When the primary steps down, all clients will
          disconnect. This is the intended behavior. While, this
@@ -417,7 +417,7 @@ To deploy a geographically distributed four-member set:
 
       .. note::
 
-         In some situations, the :method:`rs.reconfig()` shell command
+         In some situations, the :method:`rs.reconfig()` shell method
          can force the current primary to step down and causes an
          election. When the primary steps down, all clients will
          disconnect. This is the intended behavior. While, this