[1.7.x] Documentation fixes for the select_for_update change.

Refs #22343; thanks Tim Graham for the fixes.

Backport of 59b1d30 from master

3 files changed, 16 insertions, 17 deletions

diff --git a/docs/ref/models/querysets.txt b/docs/ref/models/querysets.txt
index dce93e7096..4de02bf0d9 100644
--- a/docs/ref/models/querysets.txt
+++ b/docs/ref/models/querysets.txt
@@ -1378,7 +1378,7 @@ do not support ``nowait``, such as MySQL, will cause a
 :exc:`~django.db.DatabaseError` to be raised. This is in order to prevent code
 unexpectedly blocking.
 
-Executing a queryset with ``select_for_update`` in autocommit mode is
+Evaluating a queryset with ``select_for_update`` in autocommit mode is
 an error because the rows are then not locked. If allowed, this would
 facilitate data corruption, and could easily be caused by calling,
 outside of any transaction, code that expects to be run in one.
diff --git a/docs/releases/1.6.3.txt b/docs/releases/1.6.3.txt
index c6981fa96b..f2cf261290 100644
--- a/docs/releases/1.6.3.txt
+++ b/docs/releases/1.6.3.txt
@@ -17,19 +17,19 @@ executed in autocommit mode, outside of a transaction. Before Django
 lock records until the next write operation. Django 1.6 introduced
 database-level autocommit; since then, execution in such a context
 voids the effect of ``select_for_update()``. It is, therefore, assumed
-now to be an error, and raises an exception.
-
-This change may cause test failures if you use ``select_for_update()``
-in a test class which is a subclass of
-:class:`~django.test.TransactionTestCase` rather than
-:class:`~django.test.TestCase`.  
+now to be an error and raises an exception.
 
 This change was made because such errors can be caused by including an
 app which expects global transactions (e.g. :setting:`ATOMIC_REQUESTS
-<DATABASE-ATOMIC_REQUESTS>` set to True), or Django's old autocommit
+<DATABASE-ATOMIC_REQUESTS>` set to ``True``), or Django's old autocommit
 behavior, in a project which runs without them; and further, such
 errors may manifest as data-corruption bugs.
 
+This change may cause test failures if you use ``select_for_update()``
+in a test class which is a subclass of
+:class:`~django.test.TransactionTestCase` rather than
+:class:`~django.test.TestCase`.
+
 Other bugfixes and changes
 ==========================
 
diff --git a/docs/releases/1.7.txt b/docs/releases/1.7.txt
index cb38aa3524..3f9644f7ba 100644
--- a/docs/releases/1.7.txt
+++ b/docs/releases/1.7.txt
@@ -1096,20 +1096,19 @@ executed in autocommit mode, outside of a transaction. Before Django
 lock records until the next write operation. Django 1.6 introduced
 database-level autocommit; since then, execution in such a context
 voids the effect of ``select_for_update()``. It is, therefore, assumed
-now to be an error, and raises an exception.
-
-This change may cause test failures if you use ``select_for_update()``
-in a test class which is a subclass of
-:class:`~django.test.TransactionTestCase` rather than
-:class:`~django.test.TestCase`.  
+now to be an error and raises an exception.
 
 This change was made because such errors can be caused by including an
 app which expects global transactions (e.g. :setting:`ATOMIC_REQUESTS
-<DATABASE-ATOMIC_REQUESTS>` set to True), or Django's old autocommit
+<DATABASE-ATOMIC_REQUESTS>` set to ``True``), or Django's old autocommit
 behavior, in a project which runs without them; and further, such
-errors may manifest as data-corruption bugs.
+errors may manifest as data-corruption bugs. It was also made in
+Django 1.6.3.
 
-This was also fixed in Django 1.6.3.
+This change may cause test failures if you use ``select_for_update()``
+in a test class which is a subclass of
+:class:`~django.test.TransactionTestCase` rather than
+:class:`~django.test.TestCase`.
 
 Miscellaneous
 ~~~~~~~~~~~~~