Convert tabs to spaces in a couple of rst files

These restructured text files mostly use spaces, but a few stray
tabs crept in.  Change them for consistency.

Change-Id: I89f390d02c737798007423a5126d81ad3d9e032e

2 files changed, 33 insertions, 33 deletions

diff --git a/doc/source/changeset.rst b/doc/source/changeset.rst
index 1ae070e..8aa8307 100644
--- a/doc/source/changeset.rst
+++ b/doc/source/changeset.rst
@@ -80,10 +80,10 @@ You can create a column with :meth:`~ChangesetColumn.create`:
 
   You can pass `primary_key_name`, `index_name` and `unique_name` to the
   :meth:`~ChangesetColumn.create` method to issue ``ALTER TABLE ADD
-  CONSTRAINT`` after changing the column. 
+  CONSTRAINT`` after changing the column.
 
   For multi columns constraints and other advanced configuration, check the
-  :ref:`constraint tutorial <constraint-tutorial>`. 
+  :ref:`constraint tutorial <constraint-tutorial>`.
 
   .. versionadded:: 0.6.0
 
@@ -189,30 +189,30 @@ The following rundowns are true for all constraints classes:
 
         cons = PrimaryKeyConstraint('id', 'num', table=self.table)
 
-	# Create the constraint
-	cons.create()
+        # Create the constraint
+        cons.create()
 
-	# Drop the constraint
-	cons.drop()
+        # Drop the constraint
+        cons.drop()
 
    You can also pass in :class:`~sqlalchemy.schema.Column` objects (and table
    argument can be left out):
 
    .. code-block:: python
 
-	cons = PrimaryKeyConstraint(col1, col2)
+        cons = PrimaryKeyConstraint(col1, col2)
 
 #. Some dialects support ``CASCADE`` option when dropping constraints:
 
     .. code-block:: python
 
-	cons = PrimaryKeyConstraint(col1, col2)
+        cons = PrimaryKeyConstraint(col1, col2)
 
-	# Create the constraint
-	cons.create()
+        # Create the constraint
+        cons.create()
 
-	# Drop the constraint
-	cons.drop(cascade=True)
+        # Drop the constraint
+        cons.drop(cascade=True)
 
 .. note::
     SQLAlchemy Migrate will try to guess the name of the constraints for
@@ -244,12 +244,12 @@ Foreign key constraints:
 .. code-block:: python
 
     from migrate.changeset.constraint import ForeignKeyConstraint
-    
+
     cons = ForeignKeyConstraint([table.c.fkey], [othertable.c.id])
-    
+
     # Create the constraint
     cons.create()
-    
+
     # Drop the constraint
     cons.drop()
 
@@ -258,9 +258,9 @@ Check constraints:
 .. code-block:: python
 
     from migrate.changeset.constraint import CheckConstraint
-    
+
     cons = CheckConstraint('id > 3', columns=[table.c.id])
-    
+
     # Create the constraint
     cons.create()
 
@@ -272,7 +272,7 @@ Unique constraints:
 .. code-block:: python
 
     from migrate.changeset.constraint import UniqueConstraint
-    
+
     cons = UniqueConstraint('id', 'age', table=self.table)
 
     # Create the constraint
diff --git a/doc/source/versioning.rst b/doc/source/versioning.rst
index dd413d3..7b30cd3 100644
--- a/doc/source/versioning.rst
+++ b/doc/source/versioning.rst
@@ -75,7 +75,7 @@ script applied to the database increments this version number. You can retrieve
 a database's current :term:`version`::
 
  $ python my_repository/manage.py db_version sqlite:///project.db my_repository
- 0 
+ 0
 
 A freshly versioned database begins at version 0 by default. This assumes the
 database is empty or does only contain schema elements (tables, views,
@@ -140,7 +140,7 @@ Our first change script will create a simple table
 
     account = Table(
         'account', meta,
-	Column('id', Integer, primary_key=True),
+        Column('id', Integer, primary_key=True),
         Column('login', String(40)),
         Column('passwd', String(40)),
     )
@@ -172,7 +172,7 @@ Our change script predefines two functions, currently empty:
         Column('login', String(40)),
         Column('passwd', String(40)),
     )
-  
+
 
     def upgrade(migrate_engine):
         meta.bind = migrate_engine
@@ -251,9 +251,9 @@ Our :term:`repository's <repository>` :term:`version` is::
 
     The :option:`test` command executes actual scripts, be sure you are *NOT*
     doing this on production database.
-    
+
     If you need to test production changes you should:
-    
+
         #. get a dump of your production database
         #. import the dump into an empty database
         #. run :option:`test` or :option:`upgrade` on that copy
@@ -363,7 +363,7 @@ your application - the same SQL should be generated every time, despite any
 changes to your app's source code. You don't want your change scripts' behavior
 changing when your source code does.
 
-.. warning:: 
+.. warning::
 
     **Consider the following example of what NOT to do**
 
@@ -372,7 +372,7 @@ changing when your source code does.
     .. code-block:: python
 
         from sqlalchemy import *
- 
+
         meta = MetaData()
         table = Table('mytable', meta,
             Column('id', Integer, primary_key=True),
@@ -381,7 +381,7 @@ changing when your source code does.
     ... and uses this file to create a table in a change script:
 
     .. code-block:: python
- 
+
         from sqlalchemy import *
         from migrate import *
         import model
@@ -390,7 +390,7 @@ changing when your source code does.
             model.meta.bind = migrate_engine
 
         def downgrade(migrate_engine):
-            model.meta.bind = migrate_engine 
+            model.meta.bind = migrate_engine
             model.table.drop()
 
     This runs successfully the first time. But what happens if we change the
@@ -399,7 +399,7 @@ changing when your source code does.
     .. code-block:: python
 
         from sqlalchemy import *
- 
+
         meta = MetaData()
         table = Table('mytable', meta,
             Column('id', Integer, primary_key=True),
@@ -448,7 +448,7 @@ database. Use engine.name to get the name of the database you're working with
 
  >>> from sqlalchemy import *
  >>> from migrate import *
- >>> 
+ >>>
  >>> engine = create_engine('sqlite:///:memory:')
  >>> engine.name
  'sqlite'
@@ -537,7 +537,7 @@ function names match equivalent shell commands. You can use this to
 help integrate SQLAlchemy Migrate with your existing update process.
 
 For example, the following commands are similar:
- 
+
 *From the command line*::
 
  $ migrate help help
@@ -553,9 +553,9 @@ For example, the following commands are similar:
  migrate.versioning.api.help('help')
  # Output:
  # %prog help COMMAND
- # 
+ #
  #     Displays help on a given command.
-  
+
 
 .. _migrate.versioning.api: module-migrate.versioning.api.html
 
@@ -631,7 +631,7 @@ One may also want to specify custom themes. API functions accept
 ``templates_theme`` for this purpose (which defaults to `default`)
 
 Example::
-	
+
  /home/user/templates/manage $ ls
  default.py_tmpl
  pylons.py_tmpl