Fixed #21479 -- Favor 'migrate' over 'syncdb' in the docs.

docs/faq/models.txt

@@ -45,7 +45,7 @@ Take a look at Django's support for :mod:`schema migrations
 
 If you don't mind clearing data, your project's ``manage.py`` utility has a
 :djadmin:`flush` option to reset the database to the state it was in
-immediately after :djadmin:`syncdb` was executed.
+immediately after :djadmin:`migrate` was executed.
 
 Do Django models support multiple-column primary keys?
 ------------------------------------------------------

docs/howto/custom-model-fields.txt

@@ -676,8 +676,9 @@ For example::
         def get_internal_type(self):
             return 'CharField'
 
-No matter which database backend we are using, this will mean that ``syncdb``
-and other SQL commands create the right column type for storing a string.
+No matter which database backend we are using, this will mean that
+:djadmin:`migrate` and other SQL commands create the right column type for
+storing a string.
 
 If :meth:`.get_internal_type` returns a string that is not known to Django for
 the database backend you are using -- that is, it doesn't appear in

docs/howto/initial-data.txt

@@ -78,9 +78,9 @@ Automatically loading initial data fixtures
 -------------------------------------------
 
 If you create a fixture named ``initial_data.[xml/yaml/json]``, that fixture will
-be loaded every time you run :djadmin:`syncdb`. This is extremely convenient,
+be loaded every time you run :djadmin:`migrate`. This is extremely convenient,
 but be careful: remember that the data will be refreshed *every time* you run
-:djadmin:`syncdb`. So don't use ``initial_data`` for data you'll want to edit.
+:djadmin:`migrate`. So don't use ``initial_data`` for data you'll want to edit.
 
 Where Django finds fixture files
 --------------------------------
@@ -104,7 +104,7 @@ Providing initial SQL data
 ==========================
 
 Django provides a hook for passing the database arbitrary SQL that's executed
-just after the CREATE TABLE statements when you run :djadmin:`syncdb`. You can
+just after the CREATE TABLE statements when you run :djadmin:`migrate`. You can
 use this hook to populate default records, or you could also create SQL
 functions, views, triggers, etc.
 

docs/intro/tutorial01.txt

@@ -263,9 +263,9 @@ that, run the following command:
 
 .. code-block:: bash
 
-    $ python manage.py syncdb
+    $ python manage.py migrate
 
-The :djadmin:`syncdb` command looks at the :setting:`INSTALLED_APPS` setting
+The :djadmin:`migrate` command looks at the :setting:`INSTALLED_APPS` setting
 and creates any necessary database tables according to the database settings
 in your :file:`mysite/settings.py` file. You'll see a message for each
 database table it creates, and you'll get a prompt asking you if you'd like to
@@ -281,8 +281,8 @@ display the tables Django created.
     Like we said above, the default applications are included for the common
     case, but not everybody needs them. If you don't need any or all of them,
     feel free to comment-out or delete the appropriate line(s) from
-    :setting:`INSTALLED_APPS` before running :djadmin:`syncdb`. The
-    :djadmin:`syncdb` command will only create tables for apps in
+    :setting:`INSTALLED_APPS` before running :djadmin:`migrate`. The
+    :djadmin:`migrate` command will only create tables for apps in
     :setting:`INSTALLED_APPS`.
 
 .. _creating-models:
@@ -510,17 +510,17 @@ If you're interested, also run the following commands:
 Looking at the output of those commands can help you understand what's actually
 happening under the hood.
 
-Now, run :djadmin:`syncdb` again to create those model tables in your database:
+Now, run :djadmin:`migrate` again to create those model tables in your database:
 
 .. code-block:: bash
 
-    $ python manage.py syncdb
+    $ python manage.py migrate
 
-The :djadmin:`syncdb` command runs the SQL from :djadmin:`sqlall` on your
+The :djadmin:`migrate` command runs the SQL from :djadmin:`sqlall` on your
 database for all apps in :setting:`INSTALLED_APPS` that don't already exist in
 your database. This creates all the tables, initial data and indexes for any
-apps you've added to your project since the last time you ran syncdb.
-:djadmin:`syncdb` can be called as often as you like, and it will only ever
+apps you've added to your project since the last time you ran :djadmin:`migrate`.
+:djadmin:`migrate` can be called as often as you like, and it will only ever
 create the tables that don't exist.
 
 Read the :doc:`django-admin.py documentation </ref/django-admin>` for full

docs/ref/contrib/gis/layermapping.txt

@@ -52,7 +52,7 @@ Example
         PRIMEM["Greenwich",0],
         UNIT["Degree",0.017453292519943295]]
 
-2. Now we define our corresponding Django model (make sure to use ``syncdb``)::
+2. Now we define our corresponding Django model (make sure to use :djadmin:`migrate`)::
 
     from django.contrib.gis.db import models
 

docs/ref/contrib/gis/tutorial.txt

@@ -262,8 +262,8 @@ argument. Use an integer representing the coordinate system's EPSG code.
 
 __ http://en.wikipedia.org/wiki/SRID
 
-Run ``syncdb``
---------------
+Run ``migrate``
+---------------
 
 After defining your model, you need to sync it with the database. First,
 let's look at the SQL that will generate the table for the
@@ -296,14 +296,14 @@ This command should produce the following output:
     CREATE INDEX "world_worldborder_mpoly_id" ON "world_worldborder" USING GIST ( "mpoly" GIST_GEOMETRY_OPS );
     COMMIT;
 
-If this looks correct, run ``syncdb`` to create this table in the database::
+If this looks correct, run :djadmin:`migrate` to create this table in the database::
 
-    $ python manage.py syncdb
+    $ python manage.py migrate
     Creating table world_worldborder
     Installing custom SQL for world.WorldBorder model
 
-The ``syncdb`` command may also prompt you to create an admin user. Either
-do so now, or later by running ``django-admin.py createsuperuser``.
+The :djadmin:`migrate` command may also prompt you to create an admin user.
+Either do so now, or later by running ``django-admin.py createsuperuser``.
 
 Importing Spatial Data
 ======================
@@ -742,7 +742,7 @@ Start up the Django development server:
     $ python manage.py runserver
 
 Finally, browse to ``http://localhost:8000/admin/``, and log in with the admin
-user created after running ``syncdb``.  Browse to any of the ``WorldBorder``
+user created after running :djadmin:`migrate`. Browse to any of the ``WorldBorder``
 entries -- the borders may be edited by clicking on a polygon and dragging
 the vertexes to the desired position.
 

docs/ref/models/options.txt

@@ -263,7 +263,7 @@ Django quotes column and table names behind the scenes.
     Defaults to ``('add', 'change', 'delete')``. You may customize this list,
     for example, by setting this to an empty list if your app doesn't require
     any of the default permissions. It must be specified on the model before
-    the model is created by :djadmin:`syncdb` in order to prevent any omitted
+    the model is created by :djadmin:`migrate` in order to prevent any omitted
     permissions from being created.
 
 ``proxy``

docs/topics/db/multi-db.txt

@@ -73,14 +73,14 @@ If you attempt to access a database that you haven't defined in your
 Synchronizing your databases
 ============================
 
-The :djadmin:`syncdb` management command operates on one database at a
+The :djadmin:`migrate` management command operates on one database at a
 time. By default, it operates on the ``default`` database, but by
-providing a :djadminopt:`--database` argument, you can tell syncdb to
-synchronize a different database. So, to synchronize all models onto
+providing a :djadminopt:`--database` argument, you can tell :djadmin:`migrate`
+to synchronize a different database. So, to synchronize all models onto
 all databases in our example, you would need to call::
 
-    $ ./manage.py syncdb
-    $ ./manage.py syncdb --database=users
+    $ ./manage.py migrate
+    $ ./manage.py migrate --database=users
 
 If you don't want every application to be synchronized onto a
 particular database, you can define a :ref:`database
@@ -97,7 +97,7 @@ Using other management commands
 -------------------------------
 
 The other ``django-admin.py`` commands that interact with the database
-operate in the same way as :djadmin:`syncdb` -- they only ever operate
+operate in the same way as :djadmin:`migrate` -- they only ever operate
 on one database at a time, using :djadminopt:`--database` to control
 the database used.
 
@@ -681,7 +681,7 @@ how you can split these models across databases:
   in the same database as ``sites``.
 
 In addition, some objects are automatically created just after
-:djadmin:`syncdb` creates a table to hold them in a database:
+:djadmin:`migrate` creates a table to hold them in a database:
 
 - a default ``Site``,
 - a ``ContentType`` for each model (including those not stored in that
@@ -693,7 +693,7 @@ For common setups with multiple databases, it isn't useful to have these
 objects in more than one database. Common setups include master / slave and
 connecting to external databases. Therefore, it's recommended:
 
-- either to run :djadmin:`syncdb` only for the default database;
+- either to run :djadmin:`migrate` only for the default database;
 - or to write :ref:`database router<topics-db-multi-db-routing>` that allows
   synchronizing these three models only to one database.
 

docs/topics/testing/overview.txt

@@ -1241,7 +1241,7 @@ Here's specifically what will happen:
 
 * At the start of each test case, before ``setUp()`` is run, Django will
   flush the database, returning the database to the state it was in
-  directly after :djadmin:`syncdb` was called.
+  directly after :djadmin:`migrate` was called.
 
 * Then, all the named fixtures are installed. In this example, Django will
   install any JSON fixture named ``mammals``, followed by any fixture named