Here is a number of links to resources I found useful.
If you want to host a Git repository there should normally be no shell access for all the people that need access to the repositories. So far many people have used gitosis to achieve this. Now there is a “new kid on the block”, called gitolite. I have not really used it in practice so far, but the added functionality looks promising and I also like the fact that it’s written in Perl. There is also a chapter about it in the Pro Git book.
Subversion provides a property (svn:externals) to include references to other projects into a given location within your source code tree. This is pretty much the same as a symbolic link (symlink) in Unix/Linux. But while the usage of symlinks is good practice to de-couple things in the file system, it is just the other way around for svn:externals, at least in my opinion.
Interestingly enough, there is a number of sources that recommend its usage. I disagree here and strongly discourage people from making use of it for a number of reasons:
- It creates a lock-in into Subversion, because many other Version Control Systems (VCS) do not have a comparable feature. And even if they had, an automated migration will most likely be cumbersome, to say the least. One would have to find and extract all svn:externals properties, build a dependency tree (hopefully without circular dependencies) and and process things in the appropriate order. This is far from trivial!
- On a conceptual level svn:externals is not about version control but dependency management. This is even more important an argument than the lock-in effect.
- Dependency management and version control are two entirely different things, which should not be mixed. Having a somewhat implicit mechanism to define the dependencies will make it easier for people to not have a clear understanding about this separation.
- Dependencies are hidden and only show up during VCS operations. To find out a project’s dependencies, in theory one could dig through the repository with a special browser but this is not feasible for a large enough project.
- Different dependencies can occur at different stages of an artifact’s life-cycle: compilation, unit testing, run-time etc. There is no way to reflect this requirement.
- Other dependency management systems (e.g. Maven or Ivy for Ant) offer way more functionality and can be extended for additional requirements. Those customisations would have to go into hook scripts for Subversion (which, on top of things, would probably be OS-specific).
- Quite often the dependencies will be about artifacts that are not source code at all (usually third-party libraries). You may not want to have compiled artifacts in your VCS.
- Also, the dependency could be about source code that is maintained by an external organisation. If they are not using Subversion you could not link directly there but would have to set up a mirror internally. (Admittedly, you may want to do that anyway.)
I had used svn:externals when I started out with Subversion and have gone through quite some headaches since then because of that. Practically, most of them were around the lock-in effect. Nevertheless, I still think the conceptual argument is more important in the long run.
gitosis is a nice program for hosting git repositories without having to give regular access to users. Using SSH under the covers, it basically acts as a special shell, thus limiting access to git. There are a number of nice tutorials available that explain how to make things work. I particularly liked this one. However, there is a lot of manual steps involved and a lot of errors can happen. I have therefore spent some time and started writing a few shell scripts that provide a more comfortable interface. At the moment the following scripts exist:
- gitosis-init.sh : Initializes gitosis and “installs” a regular user (not git or gitosis) for further admin work. This needs to be executed locally on the machine that runs gitosis. In order to avoid password hazzle, it is recommended to run it as root. Alternatively you can run it as the gitosis user. However, this mode has not been tested well so far. Any feedback is highly welcome.
- gitosis-add-repo.sh : Puts an existing local git repository into a remote gitosis repository.
The following scripts are currently planned for the future (other ideas are welcome!):
- Add user to gitosis (copy SSH public key over)
- Add user to repo (read/write access)
Please note that the scripts were written on Debian Lenny (v5) and so far only tested on this system. For more detailed instructions please check out the man pages (also included in the scripts).
[Update 2010-01-03: You may also want to check on gitolite, which is a gitosis rewrite in Perl with far more granular access control.]