Adapted uses of versionchanged/versionadded to the new form.

Refs #20104.

docs/topics/db/managers.txt

@@ -176,6 +176,7 @@ your choice of default manager in order to avoid a situation where overriding
 work with.
 
 .. versionchanged:: 1.6
+
     The ``get_queryset`` method was previously named ``get_query_set``.
 
 .. _managers-for-related-objects:

docs/topics/db/multi-db.txt

@@ -681,6 +681,7 @@ In addition, some objects are automatically created just after
   database).
 
 .. versionchanged:: 1.5
+
     Previously, ``ContentType`` and ``Permission`` instances were created only
     in the default database.
 

docs/topics/db/queries.txt

@@ -638,6 +638,7 @@ that were modified more than 3 days after they were published::
     >>> Entry.objects.filter(mod_date__gt=F('pub_date') + timedelta(days=3))
 
 .. versionadded:: 1.5
+
     ``.bitand()`` and ``.bitor()``
 
 The ``F()`` objects now support bitwise operations by ``.bitand()`` and
@@ -646,6 +647,7 @@ The ``F()`` objects now support bitwise operations by ``.bitand()`` and
     >>> F('somefield').bitand(16)
 
 .. versionchanged:: 1.5
+
     The previously undocumented operators ``&`` and ``|`` no longer produce
     bitwise operations, use ``.bitand()`` and ``.bitor()`` instead.
 

docs/topics/db/sql.txt

@@ -222,6 +222,7 @@ For example::
         return row
 
 .. versionchanged:: 1.6
+
     In Django 1.5 and earlier, after performing a data changing operation, you
     had to call ``transaction.commit_unless_managed()`` to ensure your changes
     were committed to the database. Since Django now defaults to database-level

docs/topics/db/transactions.txt

@@ -22,6 +22,7 @@ integrity of ORM operations that require multiple queries, especially
 <topics-db-queries-update>` queries.
 
 .. versionchanged:: 1.6
+
     Previous version of Django featured :ref:`a more complicated default
     behavior <transactions-upgrading-from-1.5>`.
 
@@ -78,6 +79,7 @@ Middleware run outside of the transaction, and so does the rendering of
 template responses.
 
 .. versionchanged:: 1.6
+
     Django used to provide this feature via ``TransactionMiddleware``, which is
     now deprecated.
 
@@ -204,6 +206,7 @@ To avoid this, you can :ref:`deactivate the transaction management
 <deactivate-transaction-management>`, but it isn't recommended.
 
 .. versionchanged:: 1.6
+
     Before Django 1.6, autocommit was turned off, and it was emulated by
     forcing a commit after write operations in the ORM.
 
@@ -224,6 +227,7 @@ where you want to run your own transaction-controlling middleware or do
 something really strange.
 
 .. versionchanged:: 1.6
+
     This used to be controlled by the ``TRANSACTIONS_MANAGED`` setting.
 
 Low-level APIs
@@ -312,10 +316,10 @@ rollback that would be performed by ``transaction.rollback()``.
 
 .. versionchanged:: 1.6
 
-When the :func:`atomic` decorator is nested, it creates a savepoint to allow
-partial commit or rollback. You're strongly encouraged to use :func:`atomic`
-rather than the functions described below, but they're still part of the
-public API, and there's no plan to deprecate them.
+    When the :func:`atomic` decorator is nested, it creates a savepoint to allow
+    partial commit or rollback. You're strongly encouraged to use :func:`atomic`
+    rather than the functions described below, but they're still part of the
+    public API, and there's no plan to deprecate them.
 
 Each of these functions takes a ``using`` argument which should be the name of
 a database for which the behavior applies.  If no ``using`` argument is
@@ -354,20 +358,20 @@ The following example demonstrates the use of savepoints::
     @transaction.atomic
     def viewfunc(request):
 
-      a.save()
-      # transaction now contains a.save()
+        a.save()
+        # transaction now contains a.save()
 
-      sid = transaction.savepoint()
+        sid = transaction.savepoint()
 
-      b.save()
-      # transaction now contains a.save() and b.save()
+        b.save()
+        # transaction now contains a.save() and b.save()
 
-      if want_to_keep_b:
-          transaction.savepoint_commit(sid)
-          # open transaction still contains a.save() and b.save()
-      else:
-          transaction.savepoint_rollback(sid)
-          # open transaction now contains only a.save()
+        if want_to_keep_b:
+            transaction.savepoint_commit(sid)
+            # open transaction still contains a.save() and b.save()
+        else:
+            transaction.savepoint_rollback(sid)
+            # open transaction now contains only a.save()
 
 Database-specific notes
 =======================