Add a concept of hosting services and known bug trackers to the Repository page

Review Request #913 — Created July 11, 2009 and submitted

Review Board SVN (deprecated)
This change revamps our Add/Change Repository pages to easily allow for specifying a repository that lives on SourceForge, Google Code, or Bitbucket. It also allows for selecting a bug tracker on Bitbucket, Bugzilla, Google Code, Redmine, SourceForge, or Trac.

Depending on the options selected, the list of supported repository types will be changed to reflect what's available on that service, and the fields available will change. For example, Google Code will present a field for the project name. The user can always choose Custom to specify their own paths.

The bug tracker selection works similarly. The fields presented are related to that specific tracker. Each field has help text to tell the user what they need. There's also a "Use hosting service's bug tracker" checkbox that is enabled for certain hosting providers. Checking this will grey out the bug tracker selection, and will use whatever bug tracker is associated with their project on the hosting service.

When creating a new repository, the project name fields (for Google Code, etc.) will be automatically entered as the user types in a repository name. If the user goes to change the project name manually, updating the repository name will no longer cause updates to these fields. This can be useful when using the project name as the repository name, saving the user some extra typing.

Internally, we have a nice list of known hosting services and bug trackers. This list contains the supported repository types, fields, and format strings for populating the database based on these fields. From this, we can reliably enter valid values (saving the user from having to specify things like "%s" in most cases) and we can also determine the proper hosting provider, bug tracker, project name, etc. based on the values saved in the database (by parsing the database values using the format strings). This prevents us from having to store extra data in the database, and also means that existing setups using Bugzilla, SourceForge, or whatever will actually say Bugzilla, SourceForge, etc. on the page the next time they go to it.
Went through and created a bunch of repositories with different hosting services, repository types, and bug trackers.

Tested all the interaction for auto-populating entries, parsing existing paths, updating fields based on selections, and saving values to the database.

I'll be working on some unit tests after this that cover all these cases more reliably. Some of these will be done using Selenium, once I finally get that infrastructure in and proper build VMs set up.
  1. The code looks pretty good, modulo some questions I have about the screenshots.
  2. Something doesn't match here :)
    1. It's too big a pain to keep the bug tracker type and project name consistent with the hosting ones, so I opt for disabling those. Yeah, they look incorrect. Not really sure what I want to do about that.
      I could take another stab at this, get it to the point where it will always be consistent even when disabled, though I think I'd like to take care of this in a separate change. I have some other work I'm toying with for remote Git support that I can't do until this is in. Perhaps I'll mess with this this week or next...
    2. Please file a bug about this when you submit.
  3. This should be disabled for custom hosting.
    1. It is disabled. That's how this theme renders it. Crappy, I know. I verified that the checkbox can't be clicked.
  4. /trunk/reviewboard/scmtools/ (Diff revision 1)