Add repo_shell project page

diff --git a/in/projects/repo_shell.md b/in/projects/repo_shell.md
new file mode 100644 (file)
index 0000000..4b30fed
--- /dev/null
+++ b/in/projects/repo_shell.md
@@ -0,0 +1,59 @@
+title: repo_shell
+linktitle: repo_shell
+parent: projects
+ctime: 2012-09-24
+mtime: 2012-09-24
+
+Repositories: [repo_shell](/gitweb/?p=repo_shell.git;a=summary).
+
+# Status
+
+[repo_shell](/gitweb/?p=repo_shell.git;a=summary) 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](/gitweb/?p=repo_shell.git;a=summary) 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](/gitweb/?p=repo_shell.git;a=summary) for git as well.
+* Resource efficient implementation suitable for deployment in a virtual
+  machine.
+
+# How to use
+
+Please read more in the
+[README](/gitweb?p=repo_shell.git;a=blob;f=README;hb=HEAD) file.
+
+# Other solutions
+
+Other solutions alreaday exists to this problem.
+
+* [gitolite](https://github.com/sitaramc/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](http://socsinfo.cs.mcgill.ca/wiki/MultiUserSVN) documents how
+  one can implement multiuser SSH key access to central subversion repositories.
+  Aside from desiring password authentication from SSH,
+  [repo_shell](/gitweb/?p=repo_shell.git;a=summary) offers no additional
+  features.
+* There are also some great solutions, like
+  [CollabNet Subversion Edge](http://www.open.collab.net/go/csvne2_r2a/) and
+  [SCM-Manager](http://www.scm-manager.org).  These are nice solutions, and
+  should be considered.  Our conclusion was that their heavier features and
+  consequently their heavier resource requirements were unnecessary.