VCS management

This week, my Version Control SoC Project saw further completions of the API functions' implementations (the API itself is completely implemented now, if I'm not mistaken) and the creation of extendable admin screens, mainly for repositories for now. There's now a list of repositories separately for each version control system, and each backend can easily customize creation, editing and display of repository information by means of hook_form_alter() and a small number of more specific hooks. Repository management is now at the same level of functionality as the one in cvs.module, only that it's generic at the basics and other backends can without much effort provide their own custom stuff, just like CVS provides CVS modules and different methods of commit information retrieval. Sure, you want screenshots:

The VCS account management page also works with user account listings, but it doesn't do much in terms of management at the moment. (Mind that an "account" is not the actual account in the VCS, but rather the association of that one to the respective Drupal user.) The problem here is that account creation is strongly connected with account approval by the VCS admin, and I can see multiple use cases of how account approval could work:

1. No admin approval is needed at all. This would be the default behaviour because it's most simple, and would mainly be used in small work environments and student teams working on university assignments, where each user is trusted to do the right thing.
2. One approval is valid for all repositories. Once users have been approved, they can create accounts in all repositories known to the site. In principle, this is the same thing that drupal.org does now, only that there's the "special case" that is just provides one single repository as well. This will especially be necessary in distributed development scenarios where new repositories are created by users when needed, and are not a one-time hurdle to fulfill and then forget about it.
3. Approval by project: when users get the ok of the project maintainer, they can create accounts in all repositories that are associated to the project. For centralized development, this means the same as approval per repository. For each repository, the user needs to apply with a separate motivation message, and each of them must separately be approved by the admin. This would be required for hosting sites like SourceForge with each projects having one or more separate repositories.
4. Approval by repository: a project has multiple repositories, and the user is only granted access to one of them. (Say, the example contributor in my distributed-VCS project may only access the development branch repository, but merging into the stable/release/master repository is only done by myself.

That makes the approval stuff very complex: the user interface (both for the user and the admin) needs to adapt to each of those use cases, and project node integration is needed (so it must be pluggable, because project node integration is a separate module). My current plan is to provide account creation without required admin approval as a basis, and provide the other methods by hooking into the account creation form for each repository with form_alter() - if the user has permission to create an account, he may do so, if not, change the form to an application one. That might work, I think. It might also mean moving the approval status / motivation text table back into the API module. There might even be multiple tables for the different approval methods. I'll have to make up my mind about that.

In any case, I thought it would be a good idea to tackle account approval and creation as next task, and proceed to project node integration afterwards.