Possibly convert over to Git as a common repository format, and then use tools (http://hg-git.github.com/) to make existing systems work with that?

what about rhodecode?

Never heard of it, but I don't think it is what I'm looking for. We already have Redmine for hosting the projects, hosting wikis, documentation, and browsing the code, etc.

What I'm specifically looking for is a wrapper that will maintain ACLs when checking out a repository via SSH. So we can say something like:

• All staff can access all repositories.
• Contractor bob can checkout and commit to project foo only.
• Contractor kate can checkout project foo, read-only, but have full access to project bar.

I think RhodeCode is exactly what you need, but it would require you to use https, I guess.

I'm working on packaging it for Debian, by the way.

I realized, later, that it would work if we were willing to switch to HTTP, but that is probably a step too far at the moment - because we're happy with redmine.

The freedesktop.org folks have a simple C program that acts like git-shell, but for many different commands. Theirs just handles git, svn, and a couple other things, but extending it to cover darcs and hg should prove trivial. That gives you the limited SSH shell you need. Then just use normal Linux accounts and permissions to control access to the repositories themselves.

I was never really fond of virtual hosting or virtual users, so if I were you I would simply create one Unix account on the server for each user, doing what it takes to restrict them to doing git or hg push. With that, the ACL system you look for already exists: Unix ACLs. Or simpler than that: Unix groups, one per project.

The downside with renaming things, or moving to one user per-project, is that we'd have to make considerable updates:

• Hudson/Jenkins checkout paths.
• Per-Host checkouts of firewalls, etc.

It could be done, but given that the current solution works - albeit without any restrictions on users - it seems like it should be possible. The gitosis/hg-gateway would be perfect if we were using only a simple DVCS system.

In the absence of any good tool suggestions it seems like we'll have to write our own.

gitolite works by using .ssh/authorized_keys and force-command, then interpreting $SSH_ORIGINAL_COMMAND to figure out what the client wanted to do.

I don't know how hg's stuff works over SSH, but it's quite likely that you could just write a small wrapper for use with force-command that checks if $SSH_ORIGINAL_COMMAND starts with git or hg, and calling the appropriate tool.

I don't think there is any, but it should be easy to extend either gitosis, gitolite or hg-gateweay to support the other system too. You only need to teach it to understand the `SSH_COMMAND` sent by the other system.

Steve, I do not understand your reply. There is no need to defined one Unix user per project, just one Unix user per user, and one group per project. After that, it is just usual Unix group membership management. And no need to rename whatever, you can still put your repositories wherever you like.

Elessar - I think I misunderstood your idea initially, thanks. Though I'd prefer not to add more users to the system - the whole idea of having all projects stored beneath ~projects was that we'd not need to create logins/accounts for other users. If I understand your suggestion fully I think you're suggesting we add unix users for each users, and then change the projects to be owned by projects:group, where the committers would be added to the group.

Everybody else: Yes, using ~/.ssh/authorized_keys is the route we expect to go down. The choice seems to be extend one of the existing wrappers to support the extra revision control systems we use, or write our own.

I think extending would be simple for most, but it comes down to whether the projects would accept being revision-control-agnostic or not. I'll look over the code and see if I can persuade the author(s) that it would be a sane choice.

Alex: I think mass-converting repositories wouldn't be something I'd enjoy doing. It's probably painless, and probably safe, but many projects are essentially mothballed and I'd rather not get into changing/updating them.