Fixed many more ReST indentation errors, somehow accidentally missed from [16955]

git-svn-id: http://code.djangoproject.com/svn/django/trunk@16983 bcc190cf-cafb-0310-a4f2-bffc1f526a37

4 files changed, 98 insertions, 98 deletions

diff --git a/docs/ref/models/fields.txt b/docs/ref/models/fields.txt
index 6c9dbf5a87..3ae35f0dc2 100644
--- a/docs/ref/models/fields.txt
+++ b/docs/ref/models/fields.txt
@@ -510,23 +510,23 @@ Has one **required** argument:
     to be passed along to the storage system. The two arguments that will be
     passed are:
 
-        ======================  ===============================================
-        Argument                Description
-        ======================  ===============================================
-        ``instance``            An instance of the model where the
-                                ``FileField`` is defined. More specifically,
-                                this is the particular instance where the
-                                current file is being attached.
+    ======================  ===============================================
+    Argument                Description
+    ======================  ===============================================
+    ``instance``            An instance of the model where the
+                            ``FileField`` is defined. More specifically,
+                            this is the particular instance where the
+                            current file is being attached.
 
-                                In most cases, this object will not have been
-                                saved to the database yet, so if it uses the
-                                default ``AutoField``, *it might not yet have a
-                                value for its primary key field*.
+                            In most cases, this object will not have been
+                            saved to the database yet, so if it uses the
+                            default ``AutoField``, *it might not yet have a
+                            value for its primary key field*.
 
-        ``filename``            The filename that was originally given to the
-                                file. This may or may not be taken into account
-                                when determining the final destination path.
-        ======================  ===============================================
+    ``filename``            The filename that was originally given to the
+                            file. This may or may not be taken into account
+                            when determining the final destination path.
+    ======================  ===============================================
 
 Also has one optional argument:
 
@@ -541,22 +541,22 @@ widget).
 Using a :class:`FileField` or an :class:`ImageField` (see below) in a model
 takes a few steps:
 
-    1. In your settings file, you'll need to define :setting:`MEDIA_ROOT` as the
-       full path to a directory where you'd like Django to store uploaded files.
-       (For performance, these files are not stored in the database.) Define
-       :setting:`MEDIA_URL` as the base public URL of that directory. Make sure
-       that this directory is writable by the Web server's user account.
+1. In your settings file, you'll need to define :setting:`MEDIA_ROOT` as the
+   full path to a directory where you'd like Django to store uploaded files.
+   (For performance, these files are not stored in the database.) Define
+   :setting:`MEDIA_URL` as the base public URL of that directory. Make sure
+   that this directory is writable by the Web server's user account.
 
-    2. Add the :class:`FileField` or :class:`ImageField` to your model, making
-       sure to define the :attr:`~FileField.upload_to` option to tell Django
-       to which subdirectory of :setting:`MEDIA_ROOT` it should upload files.
+2. Add the :class:`FileField` or :class:`ImageField` to your model, making
+   sure to define the :attr:`~FileField.upload_to` option to tell Django
+   to which subdirectory of :setting:`MEDIA_ROOT` it should upload files.
 
-    3. All that will be stored in your database is a path to the file
-       (relative to :setting:`MEDIA_ROOT`). You'll most likely want to use the
-       convenience :attr:`~django.core.files.File.url` function provided by
-       Django. For example, if your :class:`ImageField` is called ``mug_shot``,
-       you can get the absolute path to your image in a template with
-       ``{{ object.mug_shot.url }}``.
+3. All that will be stored in your database is a path to the file
+   (relative to :setting:`MEDIA_ROOT`). You'll most likely want to use the
+   convenience :attr:`~django.core.files.File.url` function provided by
+   Django. For example, if your :class:`ImageField` is called ``mug_shot``,
+   you can get the absolute path to your image in a template with
+   ``{{ object.mug_shot.url }}``.
 
 For example, say your :setting:`MEDIA_ROOT` is set to ``'/home/media'``, and
 :attr:`~FileField.upload_to` is set to ``'photos/%Y/%m/%d'``. The ``'%Y/%m/%d'``
diff --git a/docs/ref/models/instances.txt b/docs/ref/models/instances.txt
index 4ab9dd3011..d84fb3e584 100644
--- a/docs/ref/models/instances.txt
+++ b/docs/ref/models/instances.txt
@@ -34,9 +34,9 @@ Validating objects
 
 There are three steps involved in validating a model:
 
-    1. Validate the model fields
-    2. Validate the model as a whole
-    3. Validate the field uniqueness
+1. Validate the model fields
+2. Validate the model as a whole
+3. Validate the field uniqueness
 
 All three steps are performed when you call a model's
 :meth:`~Model.full_clean()` method.
@@ -211,43 +211,43 @@ What happens when you save?
 
 When you save an object, Django performs the following steps:
 
-    1. **Emit a pre-save signal.** The :doc:`signal </ref/signals>`
-       :attr:`django.db.models.signals.pre_save` is sent, allowing any
-       functions listening for that signal to take some customized
-       action.
+1. **Emit a pre-save signal.** The :doc:`signal </ref/signals>`
+   :attr:`django.db.models.signals.pre_save` is sent, allowing any
+   functions listening for that signal to take some customized
+   action.
 
-    2. **Pre-process the data.** Each field on the object is asked to
-       perform any automated data modification that the field may need
-       to perform.
+2. **Pre-process the data.** Each field on the object is asked to
+   perform any automated data modification that the field may need
+   to perform.
 
-       Most fields do *no* pre-processing — the field data is kept as-is.
-       Pre-processing is only used on fields that have special behavior.  For
-       example, if your model has a :class:`~django.db.models.DateField` with
-       ``auto_now=True``, the pre-save phase will alter the data in the object
-       to ensure that the date field contains the current date stamp. (Our
-       documentation doesn't yet include a list of all the fields with this
-       "special behavior.")
+   Most fields do *no* pre-processing — the field data is kept as-is.
+   Pre-processing is only used on fields that have special behavior.  For
+   example, if your model has a :class:`~django.db.models.DateField` with
+   ``auto_now=True``, the pre-save phase will alter the data in the object
+   to ensure that the date field contains the current date stamp. (Our
+   documentation doesn't yet include a list of all the fields with this
+   "special behavior.")
 
-    3. **Prepare the data for the database.** Each field is asked to provide
-       its current value in a data type that can be written to the database.
+3. **Prepare the data for the database.** Each field is asked to provide
+   its current value in a data type that can be written to the database.
 
-       Most fields require *no* data preparation. Simple data types, such as
-       integers and strings, are 'ready to write' as a Python object. However,
-       more complex data types often require some modification.
+   Most fields require *no* data preparation. Simple data types, such as
+   integers and strings, are 'ready to write' as a Python object. However,
+   more complex data types often require some modification.
 
-       For example, :class:`~django.db.models.DateField` fields use a Python
-       ``datetime`` object to store data. Databases don't store ``datetime``
-       objects, so the field value must be converted into an ISO-compliant date
-       string for insertion into the database.
+   For example, :class:`~django.db.models.DateField` fields use a Python
+   ``datetime`` object to store data. Databases don't store ``datetime``
+   objects, so the field value must be converted into an ISO-compliant date
+   string for insertion into the database.
 
-    4. **Insert the data into the database.** The pre-processed, prepared
-       data is then composed into an SQL statement for insertion into the
-       database.
+4. **Insert the data into the database.** The pre-processed, prepared
+   data is then composed into an SQL statement for insertion into the
+   database.
 
-    5. **Emit a post-save signal.** The signal
-       :attr:`django.db.models.signals.post_save` is sent, allowing
-       any functions listening for that signal to take some customized
-       action.
+5. **Emit a post-save signal.** The signal
+   :attr:`django.db.models.signals.post_save` is sent, allowing
+   any functions listening for that signal to take some customized
+   action.
 
 How Django knows to UPDATE vs. INSERT
 -------------------------------------
@@ -257,14 +257,14 @@ for creating and changing objects. Django abstracts the need to use ``INSERT``
 or ``UPDATE`` SQL statements. Specifically, when you call ``save()``, Django
 follows this algorithm:
 
-    * If the object's primary key attribute is set to a value that evaluates to
-      ``True`` (i.e., a value other than ``None`` or the empty string), Django
-      executes a ``SELECT`` query to determine whether a record with the given
-      primary key already exists.
-    * If the record with the given primary key does already exist, Django
-      executes an ``UPDATE`` query.
-    * If the object's primary key attribute is *not* set, or if it's set but a
-      record doesn't exist, Django executes an ``INSERT``.
+* If the object's primary key attribute is set to a value that evaluates to
+  ``True`` (i.e., a value other than ``None`` or the empty string), Django
+  executes a ``SELECT`` query to determine whether a record with the given
+  primary key already exists.
+* If the record with the given primary key does already exist, Django
+  executes an ``UPDATE`` query.
+* If the object's primary key attribute is *not* set, or if it's set but a
+  record doesn't exist, Django executes an ``INSERT``.
 
 The one gotcha here is that you should be careful not to specify a primary-key
 value explicitly when saving new objects, if you cannot guarantee the
diff --git a/docs/ref/models/options.txt b/docs/ref/models/options.txt
index 89935cc5e0..14446b69b4 100644
--- a/docs/ref/models/options.txt
+++ b/docs/ref/models/options.txt
@@ -107,21 +107,21 @@ Django quotes column and table names behind the scenes.
     the *only* difference when ``managed=False``. All other aspects of
     model handling are exactly the same as normal. This includes
 
-	1. Adding an automatic primary key field to the model if you don't
-	   declare it.  To avoid confusion for later code readers, it's
-	   recommended to specify all the columns from the database table you
-	   are modeling when using unmanaged models.
+    1. Adding an automatic primary key field to the model if you don't
+       declare it.  To avoid confusion for later code readers, it's
+       recommended to specify all the columns from the database table you
+       are modeling when using unmanaged models.
 
-	2. If a model with ``managed=False`` contains a
-	   :class:`~django.db.models.ManyToManyField` that points to another
-	   unmanaged model, then the intermediate table for the many-to-many
-	   join will also not be created. However, the intermediary table
-	   between one managed and one unmanaged model *will* be created.
+    2. If a model with ``managed=False`` contains a
+       :class:`~django.db.models.ManyToManyField` that points to another
+       unmanaged model, then the intermediate table for the many-to-many
+       join will also not be created. However, the intermediary table
+       between one managed and one unmanaged model *will* be created.
 
-	   If you need to change this default behavior, create the intermediary
-	   table as an explicit model (with ``managed`` set as needed) and use
-	   the :attr:`ManyToManyField.through` attribute to make the relation
-	   use your custom model.
+       If you need to change this default behavior, create the intermediary
+       table as an explicit model (with ``managed`` set as needed) and use
+       the :attr:`ManyToManyField.through` attribute to make the relation
+       use your custom model.
 
     For tests involving models with ``managed=False``, it's up to you to ensure
     the correct tables are created as part of the test setup.
diff --git a/docs/ref/models/relations.txt b/docs/ref/models/relations.txt
index ee6bcdd046..37986ec08d 100644
--- a/docs/ref/models/relations.txt
+++ b/docs/ref/models/relations.txt
@@ -9,28 +9,28 @@ Related objects reference
     A "related manager" is a manager used in a one-to-many or many-to-many
     related context. This happens in two cases:
 
-        * The "other side" of a :class:`~django.db.models.ForeignKey` relation.
-          That is::
+    * The "other side" of a :class:`~django.db.models.ForeignKey` relation.
+      That is::
 
-                class Reporter(models.Model):
-                    ...
+            class Reporter(models.Model):
+                ...
 
-                class Article(models.Model):
-                    reporter = models.ForeignKey(Reporter)
+            class Article(models.Model):
+                reporter = models.ForeignKey(Reporter)
 
-          In the above example, the methods below will be available on
-          the manager ``reporter.article_set``.
+      In the above example, the methods below will be available on
+      the manager ``reporter.article_set``.
 
-        * Both sides of a :class:`~django.db.models.ManyToManyField` relation::
+    * Both sides of a :class:`~django.db.models.ManyToManyField` relation::
 
-                class Topping(models.Model):
-                    ...
+            class Topping(models.Model):
+                ...
 
-                class Pizza(models.Model):
-                    toppings = models.ManyToManyField(Topping)
+            class Pizza(models.Model):
+                toppings = models.ManyToManyField(Topping)
 
-          In this example, the methods below will be available both on
-          ``topping.pizza_set`` and on ``pizza.toppings``.
+      In this example, the methods below will be available both on
+      ``topping.pizza_set`` and on ``pizza.toppings``.
 
     These related managers have some extra methods: