[full-history] Trunk merge from [3517]

git-svn-id: http://code.djangoproject.com/svn/django/branches/full-history@3519 bcc190cf-cafb-0310-a4f2-bffc1f526a37

19 files changed, 474 insertions, 58 deletions

diff --git a/docs/add_ons.txt b/docs/add_ons.txt
index 90c98b7176..6507f3b139 100644
--- a/docs/add_ons.txt
+++ b/docs/add_ons.txt
@@ -2,12 +2,15 @@
 The "contrib" add-ons
 =====================
 
-Django aims to follow Python's "batteries included" philosophy. It ships with a
-variety of extra, optional tools that solve common Web-development problems.
+Django aims to follow Python's `"batteries included" philosophy`_. It ships
+with a variety of extra, optional tools that solve common Web-development
+problems.
 
 This code lives in ``django/contrib`` in the Django distribution. Here's a
 rundown of the packages in ``contrib``:
 
+.. _"batteries included" philosophy: http://docs.python.org/tut/node12.html#batteries-included
+
 admin
 =====
 
diff --git a/docs/api_stability.txt b/docs/api_stability.txt
new file mode 100644
index 0000000000..a9d6904735
--- /dev/null
+++ b/docs/api_stability.txt
@@ -0,0 +1,123 @@
+=============
+API stability
+=============
+
+Although Django has not reached a 1.0 release, the bulk of Django's public APIs are
+stable as of the 0.95 release. This document explains which APIs will and will not
+change before the 1.0 release.
+
+What "stable" means
+===================
+
+In this context, stable means:
+
+   - All the public APIs -- everything documented in the linked documents, and
+     all methods that don't begin with an underscore -- will not be moved or
+     renamed without providing backwards-compatible aliases.
+     
+   - If new features are added to these APIs -- which is quite possible --
+     they will not break or change the meaning of existing methods. In other
+     words, "stable" does not (necessarily) mean "complete."
+     
+   - If, for some reason, an API declared stable must be removed or replaced, it
+     will be declared deprecated but will remain in the API until at least
+     version 1.1. Warnings will be issued when the deprecated method is
+     called.
+     
+   - We'll only break backwards compatibility of these APIs if a bug or
+     security hole makes it completely unavoidable.
+
+Stable APIs
+===========
+
+These APIs are stable:
+
+   - `Caching`_.
+   
+   - `Custom template tags and libraries`_ (with the possible exception for a
+     small change in the way templates are registered and loaded).
+     
+   - `Database lookup`_ (with the exception of validation; see below).
+   
+   - `django-admin utility`_.
+   
+   - `FastCGI integration`_.
+   
+   - `Flatpages`_.
+   
+   - `Generic views`_.
+   
+   - `Internationalization`_.
+   
+   - `Legacy database integration`_.
+   
+   - `Model definition`_ (with the exception of generic relations; see below).
+   
+   - `mod_python integration`_.
+   
+   - `Redirects`_.
+   
+   - `Request/response objects`_.
+   
+   - `Sending email`_.
+   
+   - `Sessions`_.
+   
+   - `Settings`_.
+   
+   - `Syndication`_.
+   
+   - `Template language`_ (with the exception of some possible disambiguation
+     of how tag arguments are passed to tags and filters).
+   
+   - `Transactions`_.
+   
+   - `URL dispatch`_.   
+   
+You'll notice that this list comprises the bulk of Django's APIs. That's right
+-- most of the changes planned between now and Django 1.0 are either under the
+hood, feature additions, or changes to a few select bits. A good estimate is
+that 90% of Django can be considered forwards-compatible at this point.
+
+That said, these APIs should *not* be considered stable, and are likely to
+change:
+
+   - `Forms and validation`_ will most likely be compeltely rewritten to
+     deemphasize Manipulators in favor of validation-aware models.
+
+   - `Serialization`_ is under heavy development; changes are likely.
+
+   - The `authentication`_ framework is changing to be far more flexible, and
+     API changes may be necessary.
+
+   - Generic relations will most likely be moved out of core and into the
+     content-types contrib package to avoid core dependacies on optional
+     components.
+
+   - The comments framework, which is yet undocumented, will likely get a complete
+     rewrite before Django 1.0. Even if the change isn't quite that drastic,
+     there will at least be moderate changes.
+     
+.. _caching: http://www.djangoproject.com/documentation/cache/
+.. _custom template tags and libraries: http://www.djangoproject.com/documentation/templates_python/
+.. _database lookup: http://www.djangoproject.com/documentation/db_api/
+.. _django-admin utility: http://www.djangoproject.com/documentation/django_admin/
+.. _fastcgi integration: http://www.djangoproject.com/documentation/fastcgi/
+.. _flatpages: http://www.djangoproject.com/documentation/flatpages/
+.. _generic views: http://www.djangoproject.com/documentation/generic_views/
+.. _internationalization: http://www.djangoproject.com/documentation/i18n/
+.. _legacy database integration: http://www.djangoproject.com/documentation/legacy_databases/
+.. _model definition: http://www.djangoproject.com/documentation/model_api/
+.. _mod_python integration: http://www.djangoproject.com/documentation/modpython/
+.. _redirects: http://www.djangoproject.com/documentation/redirects/
+.. _request/response objects: http://www.djangoproject.com/documentation/request_response/
+.. _sending email: http://www.djangoproject.com/documentation/email/
+.. _sessions: http://www.djangoproject.com/documentation/sessions/
+.. _settings: http://www.djangoproject.com/documentation/settings/
+.. _syndication: http://www.djangoproject.com/documentation/syndication/
+.. _template language: http://www.djangoproject.com/documentation/templates/
+.. _transactions: http://www.djangoproject.com/documentation/transactions/
+.. _url dispatch: http://www.djangoproject.com/documentation/url_dispatch/
+.. _forms and validation: http://www.djangoproject.com/documentation/forms/
+.. _serialization: http://www.djangoproject.com/documentation/serialization/
+.. _authentication: http://www.djangoproject.com/documentation/authentication/
diff --git a/docs/contributing.txt b/docs/contributing.txt
index d7552cdc7c..9d116cac10 100644
--- a/docs/contributing.txt
+++ b/docs/contributing.txt
@@ -168,6 +168,10 @@ Please follow these coding standards when writing code for inclusion in Django:
 
           {{foo}}
 
+    * Please don't put your name in the code. While we appreciate all
+      contributions to Django, our policy is not to publish individual
+      developer names in code -- for instance, at the top of Python modules.
+
 Committing code
 ===============
 
@@ -212,6 +216,10 @@ repository:
       first, then the "Fixed #abc." For example:
       "magic-removal: Fixed #123 -- Added whizbang feature."
 
+      For the curious: We're using a `Trac post-commit hook`_ for this.
+
+      .. _Trac post-commit hook: http://trac.edgewall.org/browser/trunk/contrib/trac-post-commit-hook
+
     * If your commit references a ticket in the Django `ticket tracker`_ but
       does *not* close the ticket, include the phrase "Refs #abc", where "abc"
       is the number of the ticket your commit references. We've rigged
diff --git a/docs/db-api.txt b/docs/db-api.txt
index ce6bb0ab3b..a7cf30813d 100644
--- a/docs/db-api.txt
+++ b/docs/db-api.txt
@@ -578,6 +578,9 @@ related ``Person`` *and* the related ``City``::
     p = b.author         # Hits the database.
     c = p.hometown       # Hits the database.
 
+Note that ``select_related()`` does not follow foreign keys that have
+``null=True``.
+
 ``extra(select=None, where=None, params=None, tables=None)``
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
diff --git a/docs/design_philosophies.txt b/docs/design_philosophies.txt
index 17ed3ad6da..7fdc7ea01b 100644
--- a/docs/design_philosophies.txt
+++ b/docs/design_philosophies.txt
@@ -274,8 +274,8 @@ Loose coupling
 A view shouldn't care about which template system the developer uses -- or even
 whether a template system is used at all.
 
-Designate between GET and POST
-------------------------------
+Differentiate between GET and POST
+----------------------------------
 
 GET and POST are distinct; developers should explicitly use one or the other.
 The framework should make it easy to distinguish between GET and POST data.
diff --git a/docs/faq.txt b/docs/faq.txt
index ccf8906c41..36fb547cf1 100644
--- a/docs/faq.txt
+++ b/docs/faq.txt
@@ -156,7 +156,7 @@ logical to us.
 -----------------------------------------------------
 
 We're well aware that there are other awesome Web frameworks out there, and
-we're not adverse to borrowing ideas where appropriate. However, Django was
+we're not averse to borrowing ideas where appropriate. However, Django was
 developed precisely because we were unhappy with the status quo, so please be
 aware that "because <Framework X>" does it is not going to be sufficient reason
 to add a given feature to Django.
@@ -251,6 +251,16 @@ information than the docs that come with the latest Django release.
 
 .. _stored in revision control: http://code.djangoproject.com/browser/django/trunk/docs
 
+Where can I find Django developers for hire?
+--------------------------------------------
+
+Consult our `developers for hire page`_ for a list of Django developers who
+would be happy to help you.
+
+You might also be interested in posting a job to http://www.gypsyjobs.com/ .
+
+.. _developers for hire page: http://code.djangoproject.com/wiki/DevelopersForHire
+
 Installation questions
 ======================
 
@@ -546,10 +556,15 @@ Set the ``CACHE_MIDDLEWARE_ANONYMOUS_ONLY`` setting to ``True``. See the
 How do I automatically set a field's value to the user who last edited the object in the admin?
 -----------------------------------------------------------------------------------------------
 
-At this point, you can't do this. But it's an oft-requested feature, so we're
-discussing how it can be implemented. The problem is we don't want to couple
-the model layer with the admin layer with the request layer (to get the current
-user). It's a tricky problem.
+At this point, Django doesn't have an official way to do this. But it's an oft-requested
+feature, so we're discussing how it can be implemented. The problem is we don't want to couple
+the model layer with the admin layer with the request layer (to get the current user). It's a
+tricky problem.
+
+One person hacked up a `solution that doesn't require patching Django`_, but note that it's an
+unofficial solution, and there's no guarantee it won't break at some point.
+
+.. _solution that doesn't require patching Django: http://lukeplant.me.uk/blog.php?id=1107301634
 
 How do I limit admin access so that objects can only be edited by the users who created them?
 ---------------------------------------------------------------------------------------------
@@ -614,3 +629,21 @@ To create a user, you'll have to use the Python API. See `creating users`_ for
 full info.
 
 .. _creating users: http://www.djangoproject.com/documentation/authentication/#creating-users
+
+Contributing code
+=================
+
+I submitted a bug fix in the ticket system several weeks ago. Why are you ignoring my patch?
+--------------------------------------------------------------------------------------------
+
+Don't worry: We're not ignoring you!
+
+It's important to understand there is a difference between "a ticket is being
+ignored" and "a ticket has not been attended to yet." Django's ticket system
+contains hundreds of open tickets, of various degrees of impact on end-user
+functionality, and Django's developers have to review and prioritize.
+
+Besides, if your feature request stands no chance of inclusion in Django, we
+won't ignore it -- we'll just close the ticket. So if your ticket is still
+open, it doesn't mean we're ignoring you; it just means we haven't had time to
+look at it yet.
diff --git a/docs/forms.txt b/docs/forms.txt
index 2fbe373744..67408f3c5d 100644
--- a/docs/forms.txt
+++ b/docs/forms.txt
@@ -404,6 +404,43 @@ Here's a simple function that might drive the above form::
             errors = new_data = {}
         form = forms.FormWrapper(manipulator, new_data, errors)
         return render_to_response('contact_form.html', {'form': form})
+        
+``FileField`` and ``ImageField`` special cases
+==============================================
+
+Dealing with ``FileField`` and ``ImageField`` objects is a little more
+complicated.
+
+First, you'll need to make sure that your ``<form>`` element correctly defines
+the ``enctype`` as ``"multipart/form-data"``, in order to upload files::
+
+  <form enctype="multipart/form-data" method="post" action="/foo/">
+
+Next, you'll need to treat the field in the template slightly differently. A
+``FileField`` or ``ImageField`` is represented by *two* HTML form elements.
+
+For example, given this field in a model::
+
+   photo = model.ImageField('/path/to/upload/location')
+
+You'd need to display two formfields in the template::
+
+   <p><label for="id_photo">Photo:</label> {{ form.photo }}{{ form.photo_file }}</p>
+
+The first bit (``{{ form.photo }}``) displays the currently-selected file,
+while the second (``{{ form.photo_file }}``) actually contains the file upload
+form field. Thus, at the validation layer you need to check the ``photo_file``
+key.
+
+Finally, in your view, make sure to access ``request.FILES``, rather than
+``request.POST``, for the uploaded files. This is necessary because
+``request.POST`` does not contain file-upload data.
+
+For example, following the ``new_data`` convention, you might do something like
+this::
+
+   new_data = request.POST.copy()
+   new_data.update(request.FILES)
 
 Validators
 ==========
diff --git a/docs/generic_views.txt b/docs/generic_views.txt
index d14fe12418..aab878467f 100644
--- a/docs/generic_views.txt
+++ b/docs/generic_views.txt
@@ -148,7 +148,8 @@ are views for displaying drilldown pages for date-based data.
 **Description:**
 
 A top-level index page showing the "latest" objects, by date. Objects with
-a date in the *future* are not included.
+a date in the *future* are not included unless you set ``allow_future`` to
+``True``.
 
 **Required arguments:**
 
@@ -185,6 +186,11 @@ a date in the *future* are not included.
     * ``mimetype``: The MIME type to use for the resulting document. Defaults
       to the value of the ``DEFAULT_MIME_TYPE`` setting.
 
+    * ``allow_future``: A boolean specifying whether to include "future"
+      objects on this page, where "future" means objects in which the field
+      specified in ``date_field`` is greater than the current date/time. By
+      default, this is ``False``.
+
 **Template name:**
 
 If ``template_name`` isn't specified, this view will use the template
@@ -217,7 +223,8 @@ In addition to ``extra_context``, the template's context will be:
 **Description:**
 
 A yearly archive page showing all available months in a given year. Objects
-with a date in the *future* are not displayed.
+with a date in the *future* are not displayed unless you set ``allow_future``
+to ``True``.
 
 **Required arguments:**
 
@@ -265,6 +272,11 @@ with a date in the *future* are not displayed.
     * ``mimetype``: The MIME type to use for the resulting document. Defaults
       to the value of the ``DEFAULT_MIME_TYPE`` setting.
 
+    * ``allow_future``: A boolean specifying whether to include "future"
+      objects on this page, where "future" means objects in which the field
+      specified in ``date_field`` is greater than the current date/time. By
+      default, this is ``False``.
+
 **Template name:**
 
 If ``template_name`` isn't specified, this view will use the template
@@ -296,7 +308,8 @@ In addition to ``extra_context``, the template's context will be:
 **Description:**
 
 A monthly archive page showing all objects in a given month. Objects with a
-date in the *future* are not displayed.
+date in the *future* are not displayed unless you set ``allow_future`` to
+``True``.
 
 **Required arguments:**
 
@@ -346,6 +359,11 @@ date in the *future* are not displayed.
     * ``mimetype``: The MIME type to use for the resulting document. Defaults
       to the value of the ``DEFAULT_MIME_TYPE`` setting.
 
+    * ``allow_future``: A boolean specifying whether to include "future"
+      objects on this page, where "future" means objects in which the field
+      specified in ``date_field`` is greater than the current date/time. By
+      default, this is ``False``.
+
 **Template name:**
 
 If ``template_name`` isn't specified, this view will use the template
@@ -378,7 +396,7 @@ In addition to ``extra_context``, the template's context will be:
 **Description:**
 
 A weekly archive page showing all objects in a given week. Objects with a date
-in the *future* are not displayed.
+in the *future* are not displayed unless you set ``allow_future`` to ``True``.
 
 **Required arguments:**
 
@@ -422,6 +440,11 @@ in the *future* are not displayed.
     * ``mimetype``: The MIME type to use for the resulting document. Defaults
       to the value of the ``DEFAULT_MIME_TYPE`` setting.
 
+    * ``allow_future``: A boolean specifying whether to include "future"
+      objects on this page, where "future" means objects in which the field
+      specified in ``date_field`` is greater than the current date/time. By
+      default, this is ``False``.
+
 **Template name:**
 
 If ``template_name`` isn't specified, this view will use the template
@@ -445,7 +468,8 @@ In addition to ``extra_context``, the template's context will be:
 **Description:**
 
 A day archive page showing all objects in a given day. Days in the future throw
-a 404 error, regardless of whether any objects exist for future days.
+a 404 error, regardless of whether any objects exist for future days, unless
+you set ``allow_future`` to ``True``.
 
 **Required arguments:**
 
@@ -501,6 +525,11 @@ a 404 error, regardless of whether any objects exist for future days.
     * ``mimetype``: The MIME type to use for the resulting document. Defaults
       to the value of the ``DEFAULT_MIME_TYPE`` setting.
 
+    * ``allow_future``: A boolean specifying whether to include "future"
+      objects on this page, where "future" means objects in which the field
+      specified in ``date_field`` is greater than the current date/time. By
+      default, this is ``False``.
+
 **Template name:**
 
 If ``template_name`` isn't specified, this view will use the template
@@ -537,7 +566,9 @@ and today's date is used instead.
 
 **Description:**
 
-A page representing an individual object.
+A page representing an individual object. If the object has a date value in the
+future, the view will throw a 404 error by default, unless you set
+``allow_future`` to ``True``.
 
 **Required arguments:**
 
@@ -604,6 +635,11 @@ A page representing an individual object.
     * ``mimetype``: The MIME type to use for the resulting document. Defaults
       to the value of the ``DEFAULT_MIME_TYPE`` setting.
 
+    * ``allow_future``: A boolean specifying whether to include "future"
+      objects on this page, where "future" means objects in which the field
+      specified in ``date_field`` is greater than the current date/time. By
+      default, this is ``False``.
+
 **Template name:**
 
 If ``template_name`` isn't specified, this view will use the template
diff --git a/docs/i18n.txt b/docs/i18n.txt
index da6983dd59..e12900c2f9 100644
--- a/docs/i18n.txt
+++ b/docs/i18n.txt
@@ -235,7 +235,7 @@ To pluralize, specify both the singular and plural forms with the
 ``{% plural %}`` tag, which appears within ``{% blocktrans %}`` and
 ``{% endblocktrans %}``. Example::
 
-    {% blocktrans count list|counted as counter %}
+    {% blocktrans count list|count as counter %}
     There is only one {{ name }} object.
     {% plural %}
     There are {{ counter }} {{ name }} objects.
diff --git a/docs/install.txt b/docs/install.txt
index 800c49b596..fb1bd73122 100644
--- a/docs/install.txt
+++ b/docs/install.txt
@@ -77,9 +77,9 @@ It's easy either way.
 Installing the official version
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-1. Download Django-0.91.tar.gz from our `download page`_.
-2. ``tar xzvf Django-0.91.tar.gz``
-3. ``cd Django-0.91``
+1. Download Django-0.95.tar.gz from our `download page`_.
+2. ``tar xzvf Django-0.95.tar.gz``
+3. ``cd Django-0.95``
 4. ``sudo python setup.py install``
 
 Note that the last command will automatically download and install setuptools_
@@ -89,14 +89,6 @@ connection.
 This will install Django in your Python installation's ``site-packages``
 directory.
 
-.. note::
-
-    Due to recent backwards-incompatible changes, it is strongly recommended
-    that you use the development version (below) for any new applications or
-    if you are just starting to work with Django. The 0.91 release is a
-    dead-end branch that is primarily of use for supporting legacy Django
-    applications.
-
 .. _setuptools: http://peak.telecommunity.com/DevCenter/setuptools
 
 Installing the development version
diff --git a/docs/release_notes_0.95.txt b/docs/release_notes_0.95.txt
new file mode 100644
index 0000000000..e5b89e5a7a
--- /dev/null
+++ b/docs/release_notes_0.95.txt
@@ -0,0 +1,126 @@
+=================================
+Django version 0.95 release notes
+=================================
+
+
+Welcome to the Django 0.95 release.
+
+This represents a significant advance in Django development since the 0.91
+release in January 2006. The details of every change in this release would be
+too extensive to list in full, but a summary is presented below.
+
+Suitability and API stability
+=============================
+
+This release is intended to provide a stable reference point for developers
+wanting to work on production-level applications that use Django.
+
+However, it's not the 1.0 release, and we'll be introducing further changes
+before 1.0. For a clear look at which areas of the framework will change (and
+which ones will *not* change) before 1.0, see the api-stability.txt file, which
+lives in the docs/ directory of the distribution.
+
+You may have a need to use some of the features that are marked as
+"subject to API change" in that document, but that's OK with us as long as it's
+OK with you, and as long as you understand APIs may change in the future.
+
+Fortunately, most of Django's core APIs won't be changing before version 1.0.
+There likely won't be as big of a change between 0.95 and 1.0 versions as there
+was between 0.91 and 0.95.
+
+Changes and new features
+========================
+
+The major changes in this release (for developers currently using the 0.91
+release) are a result of merging the 'magic-removal' branch of development.
+This branch removed a number of constraints in the way Django code had to be
+written that were a consequence of decisions made in the early days of Django,
+prior to its open-source release. It's now possible to write more natural,
+Pythonic code that works as expected, and there's less "black magic" happening
+behind the scenes.
+
+Aside from that, another main theme of this release is a dramatic increase in
+usability. We've made countless improvements in error messages, documentation,
+etc., to improve developers' quality of life.
+
+The new features and changes introduced in 0.95 include:
+
+    * Django now uses a more consistent and natural filtering interface for
+      retrieving objects from the database.
+
+    * User-defined models, functions and constants now appear in the module
+      namespace they were defined in. (Previously everything was magically
+      transferred to the django.models.* namespace.)
+
+    * Some optional applications, such as the FlatPage, Sites and Redirects
+      apps, have been decoupled and moved into django.contrib. If you don't
+      want to use these applications, you no longer have to install their
+      database tables.
+
+    * Django now has support for managing database transactions.
+
+    * We've added the ability to write custom authentication and authorization
+      backends for authenticating users against alternate systems, such as
+      LDAP.
+
+    * We've made it easier to add custom table-level functions to models,
+      through a new "Manager" API.
+
+    * It's now possible to use Django without a database. This simply means
+      that the framework no longer requires you to have a working database set
+      up just to serve dynamic pages. In other words, you can just use
+      URLconfs/views on their own. Previously, the framework required that a
+      database be configured, regardless of whether you actually used it.
+
+    * It's now more explicit and natural to override save() and delete()
+      methods on models, rather than needing to hook into the pre_save() and
+      post_save() method hooks.
+
+    * Individual pieces of the framework now can be configured without
+      requiring the setting of an environment variable. This permits use of,
+      for example, the Django templating system inside other applications.
+
+    * More and more parts of the framework have been internationalized, as
+      we've expanded internationalization (i18n) support. The Django
+      codebase, including code and templates, has now been translated, at least
+      in part, into 31 languages. From Arabic to Chinese to Hungarian to Welsh,
+      it is now possible to use Django's admin site in your native language.
+
+The number of changes required to port from 0.91-compatible code to the 0.95
+code base are significant in some cases. However, they are, for the most part,
+reasonably routine and only need to be done once. A list of the necessary
+changes is described in the `Removing The Magic`_ wiki page. There is also an
+easy checklist_ for reference when undertaking the porting operation.
+
+.. _Removing The Magic: http://code.djangoproject.com/wiki/RemovingTheMagic
+.. _checklist: http://code.djangoproject.com/wiki/MagicRemovalCheatSheet1
+
+Problem reports and getting help
+================================
+
+Need help resolving a problem with Django? The documentation in the
+distribution is also available online_ at the `Django website`_. The FAQ_
+document is especially recommended, as it contains a number of issues that
+come up time and again.
+
+For more personalized help, the `django-users`_ mailing list is a very active
+list, with more than 2,000 subscribers who can help you solve any sort of
+Django problem. We recommend you search the archives first, though, because
+many common questions appear with some regularity, and any particular problem
+may already have been answered.
+
+Finally, for those who prefer the more immediate feedback offered by IRC,
+there's a #django channel or irc.freenode.net that is regularly populated by
+Django users and developers from around the world. Friendly people are usually
+available at any hour of the day -- to help, or just to chat.
+
+.. _online: http://www.djangoproject.com/documentation/
+.. _Django website: http://www.djangoproject.com/
+.. _FAQ: http://www.djangoproject.com/documentation/faq/
+.. _django-users: http://groups.google.com/group/django-users
+
+Thanks for using Django!
+
+The Django Team
+July 2006
+
diff --git a/docs/syndication_feeds.txt b/docs/syndication_feeds.txt
index c84785b20b..b00af200a0 100644
--- a/docs/syndication_feeds.txt
+++ b/docs/syndication_feeds.txt
@@ -427,7 +427,7 @@ This example illustrates all possible attributes and methods for a ``Feed`` clas
             author's e-mail as a normal Python string.
             """
 
-        def author_name(self):
+        def author_email(self):
             """
             Returns the feed's author's e-mail as a normal Python string.
             """
diff --git a/docs/templates.txt b/docs/templates.txt
index 6117bf7b84..49d30018fe 100644
--- a/docs/templates.txt
+++ b/docs/templates.txt
@@ -363,10 +363,15 @@ extends
 
 Signal that this template extends a parent template.
 
-This tag may be used in two ways: ``{% extends "base.html" %}`` (with quotes)
-uses the literal value "base.html" as the name of the parent template to
-extend, or ``{% extends variable %}`` uses the value of ``variable`` as the
-name of the parent template to extend.
+This tag can be used in two ways: 
+
+   * ``{% extends "base.html" %}`` (with quotes) uses the literal value
+     ``"base.html"`` as the name of the parent template to extend.
+
+   * ``{% extends variable %}`` uses the value of ``variable``. If the variable
+     evaluates to a string, Django will use that string as the name of the
+     parent template. If the variable evaluates to a ``Template`` object,
+     Django will use that object as the parent template.
 
 See `Template inheritance`_ for more information.
 
@@ -493,6 +498,11 @@ If you need to combine ``and`` and ``or`` to do advanced logic, just use nested
         {% endif %}
     {% endif %}
 
+Multiple uses of the same logical operator are fine, as long as you use the
+same operator. For example, this is valid::
+
+    {% if athlete_list or coach_list or parent_list or teacher_list %}
+
 ifchanged
 ~~~~~~~~~
 
diff --git a/docs/templates_python.txt b/docs/templates_python.txt
index d353abb5bc..95ccfb3eab 100644
--- a/docs/templates_python.txt
+++ b/docs/templates_python.txt
@@ -198,21 +198,6 @@ some things to keep in mind:
 How invalid variables are handled
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-In Django 0.91, if a variable doesn't exist, the template system fails
-silently. The variable is replaced with an empty string::
-
-    >>> t = Template("My name is {{ my_name }}.")
-    >>> c = Context({"foo": "bar"})
-    >>> t.render(c)
-    "My name is ."
-
-This applies to any level of lookup::
-
-    >>> t = Template("My name is {{ person.fname }} {{ person.lname }}.")
-    >>> c = Context({"person": {"fname": "Stan"}})
-    >>> t.render(c)
-    "My name is Stan ."
-
 If a variable doesn't exist, the template system inserts the value of the
 ``TEMPLATE_STRING_IF_INVALID`` setting, which is set to ``''`` (the empty
 string) by default.
@@ -357,7 +342,7 @@ django.core.context_processors.request
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 If ``TEMPLATE_CONTEXT_PROCESSORS`` contains this processor, every
-``DjangoContext`` will contain a variable ``request``, which is the current
+``RequestContext`` will contain a variable ``request``, which is the current
 `HttpRequest object`_. Note that this processor is not enabled by default;
 you'll have to activate it.
 
diff --git a/docs/transactions.txt b/docs/transactions.txt
index c1cd5aa984..2b0755a257 100644
--- a/docs/transactions.txt
+++ b/docs/transactions.txt
@@ -2,7 +2,8 @@
 Managing database transactions
 ==============================
 
-Django gives you a few ways to control how database transactions are managed.
+Django gives you a few ways to control how database transactions are managed,
+if you're using a database that supports transactions.
 
 Django's default transaction behavior
 =====================================
@@ -144,3 +145,19 @@ Thus, this is best used in situations where you want to run your own
 transaction-controlling middleware or do something really strange. In almost
 all situations, you'll be better off using the default behavior, or the
 transaction middleware, and only modify selected functions as needed.
+
+Transactions in MySQL
+=====================
+
+If you're using MySQL, your tables may or may not support transactions; it
+depends on your MySQL version and the table types you're using. (By
+"table types," we mean something like "InnoDB" or "MyISAM".) MySQL transaction
+peculiarities are outside the scope of this article, but the MySQL site has
+`information on MySQL transactions`_.
+
+If your MySQL setup does *not* support transactions, then Django will function
+in auto-commit mode: Statements will be executed and committed as soon as
+they're called. If your MySQL setup *does* support transactions, Django will
+handle transactions as explained in this document.
+
+.. _information on MySQL transactions: http://dev.mysql.com/books/mysqlpress/mysql-tutorial/ch10.html
diff --git a/docs/tutorial01.txt b/docs/tutorial01.txt
index 62db8ab842..1113b603da 100644
--- a/docs/tutorial01.txt
+++ b/docs/tutorial01.txt
@@ -81,7 +81,7 @@ the following output on the command line::
     Validating models...
     0 errors found.
 
-    Django version 0.95 (post-magic-removal), using settings 'mysite.settings'
+    Django version 0.95, using settings 'mysite.settings'
     Development server is running at http://127.0.0.1:8000/
     Quit the server with CONTROL-C (Unix) or CTRL-BREAK (Windows).
 
diff --git a/docs/tutorial02.txt b/docs/tutorial02.txt
index 84eae3eb83..bc1717e67c 100644
--- a/docs/tutorial02.txt
+++ b/docs/tutorial02.txt
@@ -54,7 +54,8 @@ http://127.0.0.1:8000/admin/. You should see the admin's login screen:
 Enter the admin site
 ====================
 
-Now, try logging in. You should see the Django admin index page:
+Now, try logging in. (You created a superuser account in the first part of this
+tutorial, remember?) You should see the Django admin index page:
 
 .. image:: http://media.djangoproject.com/img/doc/tutorial/admin02t.png
    :alt: Django admin index page
diff --git a/docs/tutorial04.txt b/docs/tutorial04.txt
index 8ef4a03c6d..f234ed0ce1 100644
--- a/docs/tutorial04.txt
+++ b/docs/tutorial04.txt
@@ -198,7 +198,7 @@ By default, the ``object_detail`` generic view uses a template called
 ``vote()``.
 
 Similarly, the ``object_list`` generic view uses a template called
-``<app name>/<module name>_list.html``. Thus, rename ``poll/index.html`` to
+``<app name>/<module name>_list.html``. Thus, rename ``polls/index.html`` to
 ``polls/poll_list.html``.
 
 Because we have more than one entry in the URLconf that uses ``object_detail``
@@ -206,7 +206,7 @@ for the polls app, we manually specify a template name for the results view:
 ``template_name='polls/results.html'``. Otherwise, both views would use the same
 template. Note that we use ``dict()`` to return an altered dictionary in place.
 
-In previous versions of the tutorial, the templates have been provided with a context
+In previous parts of the tutorial, the templates have been provided with a context
 that contains the ``poll` and ``latest_poll_list`` context variables. However,
 the generic views provide the variables ``object`` and ``object_list`` as context.
 Therefore, you need to change your templates to match the new context variables.
diff --git a/docs/url_dispatch.txt b/docs/url_dispatch.txt
index 498a906d5e..6158014fc8 100644
--- a/docs/url_dispatch.txt
+++ b/docs/url_dispatch.txt
@@ -263,12 +263,12 @@ Here's the example URLconf from the `Django overview`_::
     from django.conf.urls.defaults import *
 
     urlpatterns = patterns('',
-        (r'^articles/(\d{4})/$', 'myproject.news.views.year_archive'),
-        (r'^articles/(\d{4})/(\d{2})/$', 'myproject.news.views.month_archive'),
-        (r'^articles/(\d{4})/(\d{2})/(\d+)/$', 'myproject.news.views.article_detail'),
+        (r'^articles/(\d{4})/$', 'mysite.news.views.year_archive'),
+        (r'^articles/(\d{4})/(\d{2})/$', 'mysite.news.views.month_archive'),
+        (r'^articles/(\d{4})/(\d{2})/(\d+)/$', 'mysite.news.views.article_detail'),
     )
 
-In this example, each view has a common prefix -- ``'myproject.news.views'``.
+In this example, each view has a common prefix -- ``'mysite.news.views'``.
 Instead of typing that out for each entry in ``urlpatterns``, you can use the
 first argument to the ``patterns()`` function to specify a prefix to apply to
 each view function.
@@ -277,7 +277,7 @@ With this in mind, the above example can be written more concisely as::
 
     from django.conf.urls.defaults import *
 
-    urlpatterns = patterns('myproject.news.views',
+    urlpatterns = patterns('mysite.news.views',
         (r'^articles/(\d{4})/$', 'year_archive'),
         (r'^articles/(\d{4})/(\d{2})/$', 'month_archive'),
         (r'^articles/(\d{4})/(\d{2})/(\d+)/$', 'article_detail'),
@@ -389,3 +389,45 @@ to pass metadata and options to views.
 
 .. _generic views: http://www.djangoproject.com/documentation/generic_views/
 .. _syndication framework: http://www.djangoproject.com/documentation/syndication/
+
+Passing extra options to ``include()``
+--------------------------------------
+
+**New in the Django development version.**
+
+Similarly, you can pass extra options to ``include()``. When you pass extra
+options to ``include()``, *each* line in the included URLconf will be passed
+the extra options.
+
+For example, these two URLconf sets are functionally identical:
+
+Set one::
+
+    # main.py
+    urlpatterns = patterns('',
+        (r'^blog/', include('inner'), {'blogid': 3}),
+    )
+
+    # inner.py
+    urlpatterns = patterns('',
+        (r'^archive/$', 'mysite.views.archive'),
+        (r'^about/$', 'mysite.views.about'),
+    )
+
+Set two::
+
+    # main.py
+    urlpatterns = patterns('',
+        (r'^blog/', include('inner')),
+    )
+
+    # inner.py
+    urlpatterns = patterns('',
+        (r'^archive/$', 'mysite.views.archive', {'blogid': 3}),
+        (r'^about/$', 'mysite.views.about', {'blogid': 3}),
+    )
+
+Note that extra options will *always* be passed to *every* line in the included
+URLconf, regardless of whether the line's view actually accepts those options
+as valid. For this reason, this technique is only useful if you're certain that
+every view in the the included URLconf accepts the extra options you're passing.