Merge pull request #126 from fwong03/bugfix/typos

Fix a few typos in documentation

doc/guide/index.rst

@@ -3,7 +3,7 @@ ZODB programming guide
 ======================
 
 This guide consists of a collection of topics that should be of
-interest to most developers.  They're provuded in order of importance,
+interest to most developers.  They're provided in order of importance,
 which is also an order from least to most advanced, but they can be
 read in any order.
 

doc/guide/install-and-run.rst

@@ -123,9 +123,9 @@ configuration to be reduced to a single URI and handles most cases.
 Using databases: connections
 ============================
 
-Once you have a database, you need to get a database connection to to
+Once you have a database, you need to get a database connection to do
 much of anything.  Connections take care of loading and saving objects
-and manage object caches. Each connection has it's own cache
+and manage object caches. Each connection has its own cache
 [#caches-are-expensive]_.
 
 .. _getting-connections:

doc/guide/transactions-and-threading.rst

@@ -151,7 +151,7 @@ them with the ``with`` statement directly::
 
 When used as a context manager, a transaction manager explicitly
 begins a new transaction, executes the code block and commits the
-transaction if there isn't an error and aborts it of there is an
+transaction if there isn't an error and aborts it if there is an
 error.
 
 We used ``as trans`` above to get the transaction.
@@ -242,7 +242,7 @@ connections will get a conflict error when it tries to commit::
     ...
     ZODB.POSException.ConflictError: ...
 
-If we executed this code, we'd get ``ConflictError`` exception on the
+If we executed this code, we'd get a ``ConflictError`` exception on the
 last line.  After a conflict error is raised, we'd need to abort the
 transaction, or begin a new one, at which point we'd see the data as
 written by the other connection:
@@ -267,7 +267,7 @@ Retrying transactions
 ~~~~~~~~~~~~~~~~~~~~~
 
 The most common way to deal with conflict errors is to catch them and
-retry transactions.  To do this manually, involves code that looks
+retry transactions.  To do this manually involves code that looks
 something like this::
 
   max_attempts = 3
@@ -325,12 +325,12 @@ Commonly used objects that implement conflict resolution are
 buckets and ``Length`` objects provided by the `BTree
 <https://pythonhosted.org/BTrees/>`_ package.
 
-The main data structures provided by BTrees: BTrees and TreeSets,
+The main data structures provided by BTrees, BTrees and TreeSets,
 spread their data over multiple objects.  The leaf-level objects,
 called *buckets*, allow distinct keys to be updated without causing
 conflicts [#usually-avoids-conflicts]_.
 
-``Length`` objects are conflict-free counters, that merge changes by
+``Length`` objects are conflict-free counters that merge changes by
 simply accumulating changes.
 
 .. caution::
@@ -353,7 +353,7 @@ can be broken in non-obvious ways. For example a Web API that splits
 logical operations over multiple web requests, as is often done in
 `REST
 <https://en.wikipedia.org/wiki/Representational_state_transfer>`_
-APIs, violate this rule.
+APIs, violates this rule.
 
 Partial transaction error recovery using savepoints
 ---------------------------------------------------
@@ -395,7 +395,7 @@ ZODB supports concurrency through transactions.  Multiple programs
 [#wtf-program]_ can operate independently in separate transactions.
 They synchronize at transaction boundaries.
 
-The most common way to run ZODB is with each program running in it's
+The most common way to run ZODB is with each program running in its
 own thread.  Usually the thread-local transaction manager is used.
 
 You can use multiple threads per transaction and you can run multiple
@@ -441,7 +441,7 @@ Some things to keep in mind when utilizing multiple processes:
    split due to added objects causing them to exceed their maximum size.
 
 .. [#undo] Transactions can't be rolled back, but they may be undone
-   in some cases, especially of subsequent transactions
+   in some cases, especially if subsequent transactions
    haven't modified the same objects.
 
 .. [#bad-idea-using-multiple-threads-per-transaction] While it's

doc/guide/writing-persistent-objects.rst

@@ -530,7 +530,7 @@ to store the value. Later they are used to look it up via ``in`` or
 ``__getitem__``.
 
 When that ``dict`` is later loaded from the database, the internal
-storage is rebuild from scratch. This means that every key has its
+storage is rebuilt from scratch. This means that every key has its
 ``__hash__`` method called at least once, and may have its ``__eq__``
 method called many times.
 
@@ -538,7 +538,7 @@ By default, every object, including persistent objects, inherits an
 implementation of ``__eq__`` and ``__hash__`` from :class:`object`.
 These default implementations are based on the object's *identity*,
 that is, its unique identifier within the current Python process.
-Calling, them, therefore is very fast, even on :ref:`ghosts
+Calling them, therefore, is very fast, even on :ref:`ghosts
 <ghost-label>`, and doesn't cause a ghost to load its state.
 
 If you override ``__eq__`` and ``__hash__`` in a custom persistent

doc/tutorial.rst

@@ -201,7 +201,7 @@ Memory Management
 
 ZODB manages moving objects in and out of memory for you.  The unit of
 storage is the persistent object.  When you access attributes of a
-persistent objects, it's loaded from the database automatically, if
+persistent object, they are loaded from the database automatically, if
 necessary. If too many objects are in memory, then objects used least
 recently are evicted [#eviction]_.  The maximum number of objects or
 bytes in memory is configurable.