Removed the syncdb command per deprecation timeline.

django/core/management/__init__.py

@@ -81,7 +81,7 @@ def call_command(name, *args, **options):
     This is the primary API you should use for calling specific commands.
 
     Some examples:
-        call_command('syncdb')
+        call_command('migrate')
         call_command('shell', plain=True)
         call_command('sqlmigrate', 'myapp')
     """

django/core/management/commands/syncdb.py

@@ -1,45 +0,0 @@
-import warnings
-
-from django.apps import apps
-from django.contrib.auth import get_user_model
-from django.db import DEFAULT_DB_ALIAS
-from django.core.management import call_command
-from django.core.management.base import BaseCommand
-from django.utils.deprecation import RemovedInDjango19Warning
-from django.utils.six.moves import input
-
-
-class Command(BaseCommand):
-    help = "Deprecated - use 'migrate' instead."
-
-    def add_arguments(self, parser):
-        parser.add_argument('--noinput', action='store_false', dest='interactive', default=True,
-            help='Tells Django to NOT prompt the user for input of any kind.')
-        parser.add_argument('--no-initial-data', action='store_false', dest='load_initial_data', default=True,
-            help='Tells Django not to load any initial data after database synchronization.')
-        parser.add_argument('--database', default=DEFAULT_DB_ALIAS,
-            help='Nominates a database to synchronize. Defaults to the "default" database.')
-
-    def handle(self, **options):
-        warnings.warn("The syncdb command will be removed in Django 1.9", RemovedInDjango19Warning)
-        call_command("migrate", **options)
-
-        try:
-            apps.get_model('auth', 'Permission')
-        except LookupError:
-            return
-
-        UserModel = get_user_model()
-
-        if not UserModel._default_manager.exists() and options.get('interactive'):
-            msg = ("\nYou have installed Django's auth system, and "
-                "don't have any superusers defined.\nWould you like to create one "
-                "now? (yes/no): ")
-            confirm = input(msg)
-            while 1:
-                if confirm not in ('yes', 'no'):
-                    confirm = input('Please enter either "yes" or "no": ')
-                    continue
-                if confirm == 'yes':
-                    call_command("createsuperuser", interactive=True, database=options['database'])
-                break

django/db/backends/base/schema.py

@@ -24,7 +24,7 @@ class BaseDatabaseSchemaEditor(object):
     It is intended to eventually completely replace DatabaseCreation.
 
     This class should be used by creating an instance for each set of schema
-    changes (e.g. a syncdb run, a migration file), and by first calling start(),
+    changes (e.g. a migration file), and by first calling start(),
     then the relevant actions, and then commit(). This is necessary to allow
     things like circular foreign key references - FKs will only be created once
     commit() is called.

django/db/migrations/recorder.py

@@ -11,7 +11,7 @@ class MigrationRecorder(object):
     Deals with storing migration records in the database.
 
     Because this table is actually itself used for dealing with model
-    creation, it's the one thing we can't do normally via syncdb or migrations.
+    creation, it's the one thing we can't do normally via migrations.
     We manually handle table creation/schema updating (using schema backend)
     and then have a floating model to do queries with.
 

docs/ref/django-admin.txt

@@ -751,10 +751,6 @@ The behavior of this command changes depending on the arguments provided:
   migrated past the named migration. Use the name ``zero`` to unapply all
   migrations for an app.
 
-Unlike ``syncdb``, this command does not prompt you to create a superuser if
-one doesn't exist (assuming you are using :mod:`django.contrib.auth`). Use
-:djadmin:`createsuperuser` to do that if you wish.
-
 The :djadminopt:`--database` option can be used to specify the database to
 migrate.
 
@@ -1264,19 +1260,6 @@ for :djadmin:`startapp`.
 
 .. _`template source`: https://github.com/django/django/tree/master/django/conf/project_template/
 
-syncdb
-------
-
-.. django-admin:: syncdb
-
-.. deprecated:: 1.7
-
-    This command has been deprecated in favor of the :djadmin:`migrate`
-    command, which performs both the old behavior as well as executing
-    migrations. It is now just an alias to that command.
-
-Alias for :djadmin:`migrate`.
-
 test <app or test identifier>
 -----------------------------
 

docs/releases/1.1.txt

@@ -224,7 +224,7 @@ A number of features have been added to Django's model layer:
 You can now control whether or not Django manages the life-cycle of the database
 tables for a model using the :attr:`~Options.managed` model option. This
 defaults to ``True``, meaning that Django will create the appropriate database
-tables in :djadmin:`syncdb` and remove them as part of the ``reset``
+tables in ``syncdb`` and remove them as part of the ``reset``
 command. That is, Django *manages* the database table's lifecycle.
 
 If you set this to ``False``, however, no database table creating or deletion

docs/releases/1.2.5.txt

@@ -105,7 +105,7 @@ the policy that data inserted by custom SQL will *not* be visible
 during testing.
 
 This change only affects the testing process. You can still use custom
-SQL to load data into your production database as part of the syncdb
+SQL to load data into your production database as part of the ``syncdb``
 process. If you require data to exist during test conditions, you
 should either insert it using :ref:`test fixtures
 <topics-testing-fixtures>`, or using the ``setUp()`` method of your

docs/releases/1.3.txt

@@ -553,7 +553,7 @@ the policy that data inserted by custom SQL will *not* be visible
 during testing.
 
 This change only affects the testing process. You can still use custom
-SQL to load data into your production database as part of the syncdb
+SQL to load data into your production database as part of the ``syncdb``
 process. If you require data to exist during test conditions, you
 should either insert it using :ref:`test fixtures
 <topics-testing-fixtures>`, or using the ``setUp()`` method of your

docs/releases/1.5.txt

@@ -627,16 +627,16 @@ with the :meth:`~django.forms.Form.is_valid()` method and not with the
 presence or absence of the :attr:`~django.forms.Form.cleaned_data` attribute
 on the form.
 
-Behavior of :djadmin:`syncdb` with multiple databases
+Behavior of ``syncdb`` with multiple databases
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-:djadmin:`syncdb` now queries the database routers to determine if content
+``syncdb`` now queries the database routers to determine if content
 types (when :mod:`~django.contrib.contenttypes` is enabled) and permissions
 (when :mod:`~django.contrib.auth` is enabled) should be created in the target
 database. Previously, it created them in the default database, even when
 another database was specified with the :djadminopt:`--database` option.
 
-If you use :djadmin:`syncdb` on multiple databases, you should ensure that
+If you use ``syncdb`` on multiple databases, you should ensure that
 your routers allow synchronizing content types and permissions to only one of
 them. See the docs on the :ref:`behavior of contrib apps with multiple
 databases <contrib_app_multiple_databases>` for more information.

docs/releases/1.7.txt

@@ -953,8 +953,8 @@ Backwards incompatible changes in 1.7
     deprecation timeline for a given feature, its removal may appear as a
     backwards incompatible change.
 
-allow_syncdb/allow_migrate
+``allow_syncdb`` / ``allow_migrate``
-~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 While Django will still look at ``allow_syncdb`` methods even though they
 should be renamed to ``allow_migrate``, there is a subtle difference in which
@@ -1567,7 +1567,7 @@ submodules and the ``django.contrib.contenttypes.generic`` module is deprecated:
 ``syncdb``
 ~~~~~~~~~~
 
-The :djadmin:`syncdb` command has been deprecated in favor of the new :djadmin:`migrate`
+The ``syncdb`` command has been deprecated in favor of the new :djadmin:`migrate`
 command. ``migrate`` takes the same arguments as ``syncdb`` used to plus a few
 more, so it's safe to just change the name you're calling and nothing else.
 

docs/spelling_wordlist

@@ -630,7 +630,6 @@ subwidgets
 symlink
 symlinking
 symlinks
-syncdb
 sysadmin
 systemwide
 tablespace

docs/topics/migrations.txt

@@ -12,17 +12,6 @@ Migrations are Django's way of propagating changes you make to your models
 designed to be mostly automatic, but you'll need to know when to make
 migrations, when to run them, and the common problems you might run into.
 
-A Brief History
----------------
-
-Prior to version 1.7, Django only supported adding new models to the
-database; it was not possible to alter or remove existing models via the
-``syncdb`` command (the predecessor to :djadmin:`migrate`).
-
-Third-party tools, most notably `South <http://south.aeracode.org>`_,
-provided support for these additional types of change, but it was considered
-important enough that support was brought into core Django.
-
 The Commands
 ------------
 
@@ -157,8 +146,7 @@ database to make sure they work as expected::
     Running migrations:
       Applying books.0003_auto... OK
 
-The command runs in two stages; first, it synchronizes unmigrated apps
+The command runs in two stages; first, it synchronizes unmigrated apps, and
-(performing the same functionality that ``syncdb`` used to provide), and
 then it runs any migrations that have not yet been applied.
 
 Once the migration is applied, commit the migration and the models change