Change SCMTool database registration to prevent overwriting custom SCMTool entries.

Review Request #958 — Created Aug. 12, 2009 and submitted

Information

Review Board SVN (deprecated)
trunk

Reviewers

Change SCMTool database registration to prevent overwriting custom SCMTool entries.

We had a rather nasty bug due to our use of fixtures for SCMTools that would
overwrite a user's custom SCMTool database entries whenever we added an entry.

We had all our SCMTool registrations in our initial_data.json fixture, which
hard-coded IDs. This meant that if an existing entry was in the database with
that ID, Django would overwrite the entry with what we had in our fixture.

This change moves SCMTool database registration into a management command,
"registerscmtools". This is also hooked up as a post-syncdb callback,
meaning that they just need to re-run syncdb in order to auto-add any new
SCMTools. They can, of course, still add them to the database by hand. None
of these entries will be allocated a specific ID, but instead will take the
next available.

We use a management command instead of just piggy-backing on syncdb always
as syncdb possibly could perform other operations that the user/developer
doesn't want. It's not a big deal either way, but it's trivial to have it
as a new command, so why not. In the future, we may want to tie some of these
management commands into the admin UI, and at that point it's nice to have
a separation.

The way we look up SCMTools to register is by using the setuptools extension
points mechanism. All of the SCMTools that we ship by default are registered
in a "reviewboard.scmtools" entry point. Third parties can provide their own
modules that also register into this, and Review Board will pick them up on
the next syncdb.

Most of this change is small, though every SCMTool has been updated to provide
a human-readable name that our new code can use for populating entries.
All unit tests pass.

Ran syncdb on a new database with all existing entries, and nothing was modified (as expected).

Ran syncdb on a database that had everything but ClearCase, and ClearCase was added.

Ran syncdb on a database that had everything but ClearCase *and* had a custom SCMTool in the slot that ClearCase previously would overwrite. ClearCase was added, but my existing entry was untouched.

Made sure the management command worked in these cases as well, independently of syncdb.