Repositories: repo_shell.
Status
repo_shell is early in its development cycle and should be considered alpha software. Most notably, access control mechanisms for git repositories are very new.
A login shell for source code control
repo_shell is designed to solve a particular problem here at TMI. Specifically:
- Repositories are accessed via Secure Shell (SSH). HTTPS is a valid approach now for both subversion and git, but we prefer SSH for many reasons.
- Developers can push their public SSH key to the server for password-less repository access. However, access over SSH with user passwords is also possible when needed -- an occasional need with some of our workflows.
- Repositories are owned by a system user. Developers have no direct access to repository files.
- A simple access control mechanism defines an association between developer and repository allowing one of three access levels: no access, read only, or read write.
- The access mechanisms encapsulate the respective repository type root directories as an implementation detail not needed by developers. This is commonly done with subversion repositories using the svnserve --root argument. The same feature is provided by repo_shell for git as well.
- Resource efficient implementation suitable for deployment in a virtual machine.
How to use
Please read more in the README file.
Other solutions
Other solutions alreaday exists to this problem.
- gitolite is a great solution. However, it is heavier than we need, does not support password authentication over SSH, and does not suppport subversion.
- SVN MultiUser documents how one can implement multiuser SSH key access to central subversion repositories. Aside from desiring password authentication from SSH, repo_shell offers no additional features.
- There are also some great solutions, like CollabNet Subversion Edge and SCM-Manager. These are nice solutions, and should be considered. Our conclusion was that their heavier features and consequently their heavier resource requirements were unnecessary.