You can clone with
HTTPS or Subversion.
Wanted to open this for discussion. I'd like to simplify the upgradedb process, and I can't think of any reason why you'd need syncdb if you're using nashvegas.
The only reason is that early on in projects nashvegas might be installed but a team might be quickly iterating on models where they are just blowing away and recreated the database frequently and running syncdb to avoid writing all the migrations. But I guess this is easily solved by either just not installing nashvegas until you are ready to create the initial migration or just comment it out from the INSTALLED_APPS list.
I'm a +1 on doing this but would like to hear what @brosner has to say.
Yeah, I think this will be a decent change. Of course, I'd expect upgradedb --execute to continue working, but syncdb merely being an alias.
Are we ok with the default syncdb behavior being nashvegas, and having a some flag that tells it to use Django's?
This will make nashvegas drop-in work with the test suite (which is probably desirable). It's definitely the easiest way I have of supporting the test suite without doing what South does and patching the command.
Yes. I am certainly in favor of this, especially if upgradedb -e remains in place for backwards compatibility.
This has now been implemented and is in master (but not yet packaged into a release)