option to lock project short name

Okay, this is going to need to be sorted out in the initial port to vcs_git and that is probably where the form_alter should live as well.

Actually thought some more about the mapping and naming, and I think that we may need to make a list of projects that don't map, and let the module maintainer choose whether they'd like to keep their cvs directory name, or the project's shortname, as they may have their actual module or namespace used within their module based on either. I don't think the actual mapping of occupied namespaces needs to have anything to do with this, as there is a project_info module in the works that could handle that, but you'd have to ask dww for the details.

In case there is a mismatch, it is better to keep the project short name:

1. It is used as a key for several external things: update module, testing, packages, etc.
2. We can change the repository name easily during the conversion process

Damien raises some excellent points here, since among all repos (which in cvs are broken out so that modules, themes, profiles all get their own namespace) the short name on d.o is the closest thing we have to a global namespace for all d.o projects. This also avoids linkrot or redirects on d.o.

The next question is where should this could live, vc_git, vc_project, or drupalorg?

IMHO using the project shortname is the best option, for the points mentioned in #4

I think this hook_form_alter could live in:
- project, as a global configuration flag "let modify project-shortname", or if not accepted on
- versioncontrol_project, since this is not an specific git change

Okay, I'll try to roll a patch for project that adds this.

changes in this patch

1. moves this from form_alter to the project node form itself
2. since the HTML spec doesn't pass #disabled elements in $_POST (boo...), we have to pass uri as a #value when it's locked. so, i also added a dummy form item for display in this case.
3. cleaned up a spacing issue, and a better check for a new node

You should be able to add #input => TRUE to the element for its value to be processed in the $form_state['values'].

damz's approach seems to be a bit cleaner, so i went with it. note that you also have to explicitly pass #value for type 'item' -- i guess #default_value won't work.

attached has been well tested and seems to work perfectly.

Looks RTBC to me, testing this with editing existing, and creating a new project, each with the setting enabled and disabled. The only thought I had was that it might be nice to include the explanation text when editing and locked, so that the user knows why the item is still appearing, but they can't edit.

The only thought I had was that it might be nice to include the explanation text when editing and locked, so that the user knows why the item is still appearing, but they can't edit

i had that thought as well, but decided that since it's not a form field, it's pretty obvious that it's not editable, plus they got the explanation the first time ;) i say save the screen real estate on that -- we can add it if it becomes a UI issue.

committed to 6.x-1.x-dev, and deployed on drupal.org

Here's a super short test for this.

Reviewed, tested and committed #15 to HEAD, thanks.

See also #997906: Reconcile project_allow_uri_update == FALSE and sandbox projects being promoted to full projects ... ;)