Fixed #13746: made the dumdata help message a bit clearer. Thanks, Pa…

…ulM.

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

django/core/management/commands/dumpdata.py

@@ -20,7 +20,8 @@ class Command(BaseCommand):
         make_option('-n', '--natural', action='store_true', dest='use_natural_keys', default=False,
             help='Use natural keys if they are available.'),
     )
-    help = 'Output the contents of the database as a fixture of the given format.'
+    help = ("Output the contents of the database as a fixture of the given "
+            "format (using each model's default manager).")
     args = '[appname appname.ModelName ...]'
 
     def handle(self, *app_labels, **options):
@@ -163,4 +164,4 @@ def sort_dependencies(app_list):
             )
         model_dependencies = skipped
 
-    return model_list
+    return model_list

docs/topics/db/managers.txt

@@ -170,7 +170,8 @@ and ``Person.people.all()``, yielding predictable results.
 If you use custom ``Manager`` objects, take note that the first ``Manager``
 Django encounters (in the order in which they're defined in the model) has a
 special status. Django interprets the first ``Manager`` defined in a class as
-the "default" ``Manager``, and several parts of Django will use that ``Manager``
+the "default" ``Manager``, and several parts of Django
+(including :djadmin:`dumpdata`) will use that ``Manager``
 exclusively for that model. As a result, it's a good idea to be careful in
 your choice of default manager in order to avoid a situation where overriding
 ``get_query_set()`` results in an inability to retrieve objects you'd like to