06 October 2013

Adventures in Version Control Servers Featuring Gitolite and Subversion

Article Update 26 December 2013

Both viewgit and gitweb have been unable to display the contents of repositories modified with the most recent version of git.

BitBucket offers unlimited private repositories and then charges by the user if you need to allow others access. Since I have numerous private repositories with few others who need access, I’ve been migrating to BitBucket. Both GitHub and BitBucket offer unlimited public repositories. Since, a lot of the Open Source community already use GitHub, as I work on my OpenSource projects I’m going to migrate them there to encourage collaboration and move their bug reporting from rtcpan, since github has a nicer ticket system.

Original Article

Recently I had the need to migrate two version Control Servers, one on Linux running Gitosis, the other on Windows running Subversion. The Windows Subversion Repository was being moved to an Ubuntu/12.04 Linux Server. The git server was simply moving from an older 10.04 server to a 12.04 server, unfortunately the Gitosis project has been abandoned so I had to switch to Gitolite.

The Gitolite Experience.

There are numerous articles on how to set up your own git server. Despite numerous how-to articles I spent an excessive amount of time trying to make this work because of a handful of things that none of the other authors explained.

Gitolite does not run as a service (daemon), it is a process triggered at ssh login. The config files are .hidden files in the git/gitolite user’s home directory. As a sysadmin I expected it to be a service and found it confusing that it had no global configuration and no running processes.

Until you’ve checked out and added keys to the gitolite-admin project access is a little screwy. The best advice here is to use the public key of the user who will first checkout gitolite-admin as the key specified to the setup program. However, if you need to manually add a key, you need to add the key to authorized keys (like any key being added for ssh), but follow the format of another entry – gitolite shell commands to wrap the session preceding the key. Once you commit the gitolite-admin project expect your manual changes to get wiped away.

If you’re having trouble with gitolite try to initiate a regular ssh session ‘ssh gitolite@targethost’, you should get some messages from gitolite, if you get a bash shell you did not properly prefix the key with the commands gitolite needs.

Once the new server was up and running migrating the repositories was trivial. Define the repositories in gitolite-admin/conf, then from each repository run the following  commands.

git remote rm origin
git remote add origin git@myserver:mynewrepo.git
git push origin master

Other than these issues you’ll find a number of how to documents which will do a pretty good job of getting you going. I didn’t find the Gitolite documentation very helpful. One final word, I strongly prefer viewgit to gitweb, even though more of the how-to docs seem to point to the latter. Either install both and choose for yourself or pick viewgit.

It makes no sense repeating good instructions by other authors so I’ll link a few that were relevant at the writing of this document.

The Official Documentation:

http://gitolite.com/gitolite/install.html

http://blog.countableset.ch/2012/04/29/ubuntu-12-dot-04-installing-gitolite-and-gitweb/

http://marian.schedenig.name/2012/07/29/setting-up-a-gitolite-server-in-ubuntu/

Installing ViewGit

Since there is a little less documentation for viewgit, I’ll go over it here.

Assuming that your gitolite repositories are at:

/home/git/repositories

Pre-requisite packages (ubuntu): apache2 libapache2-mod-php5 php-geshi

cd /var/www
sudo git clone http://repo.or.cz/r/viewgit.git
sudo chown -vR www-data:www-data viewgit

cd /var/www/viewgit/inc
sudo cp config.php localconfig.php
sudo chown www-data:www-data localconfig.php
sudo $EDITOR localconfig.php

Change the directive for $conf[‘projects … # watch out for a comment in the middle of the assignment. To  $conf[‘projects_glob’] = array(‘/home/git/repositories/*.git’);

Now edit the apache config for the virtual host that will serve viewgit.

Alias /viewgit /var/www/viewgit

<Directory /var/www/viewgit/>
 AuthType Digest
 AuthName "whateveryoucallit"
 AuthDigestDomain http://yourserver
 AuthDigestProvider file
 AuthUserFile /etc/secrets/.gitpasswords
 Require valid-user
 </Directory>

Use htdigest to create the password file.

Restart apache, you should be challenged to get to your repo. If you don’t want to password protect the repository then just the alias directive should suffice.

The Subversion Experience

I like git a lot better than subversion but I will observe that the Documentation for the subversion server was a lot better than for gitolite. To perform the migration required completely dumping and then importing the repository, which took a long time. With Gitolite, once the new server was up cloning back to the new server was much quicker since git uses both compression and deltas as opposed to subversion which repeats the whole repo over with each revision.