Change SCMTool database registration to prevent overwriting custom SCMTool entries.
Review Request #958 — Created Aug. 12, 2009 and submitted — Latest diff uploaded
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.