Installing Trac (with git) in Fedora 15/16 [Part 2]

My previous post got trac setup and running with SVN as the version control system. This post will show you how to get trac working with git as the version control system. When you installed trac using the command in the last post you will have also installed the trac git plugin. If you did not do so then you can set it up by running the following:


$ su -c "yum install trac-git-plugin"

It also assumes that you have it installed, If you don’t you can install it using:


$ su -c "yum install git"

Creating a git repository

In order to get trac to use the repository you have to set it up first. In this howto I will set up a local repository as the trac server is on the same machine I do development work on. You can use ssh to commit to the git repository remotely. There are many guides online on how to do this, so I won’t cover it here. You can create the folder to store your git repo anywhere, by convention they usually end in .git, and to keep everything contained I’m going to store it in my trac directory.


$ cd /home/webpigeon/trac
$ mkdir repo.git
$ cd repo.git
$ git init --bare

Setting up Trac-Git

Now we have the git repo setup (although empty) we can now setup the Git Trac plugin. This process involves editing the trac configuration file in your favourite editor. The editor I’ll use it vi, but you could use emacs, nano or a graphical editor like gedit if you prefer.


$ vi conf/trac.ini

First we have to enable the git plug-in. The easiest way to do this is to locate the “[components]” section in trac.ini. I couldn’t find this in my version, so I added it. This will enable the git plug-in. If you don’t do this step you will get a lovely warning message when you use trac stating, “Warning: Can’t synchronise with repository “(default)” (Unsupported version control system “git”: Can’t find an appropriate component, maybe the corresponding plug-in was not enabled? ). Look in the Trac log for more information.”. If you have added the below and you still get the error check that you installed the plug-in back in step 1.


[components]
tracext.git.git_fs.* = enabled

Locate the “[trac]” section in trac.ini. Under this section you will need to edit repository_dir and repository_type, there are plenty of other options in this section but you can ignore them. Repository type should be set to the full path to your repository which you just created and repository type should be set to git. If your path includes spaces you should probably put it in quotes, to be on the safe side (although I’ve not tried this).


[trac]
# other stuff is here
repository_dir = /home/webpigeon/trac/repo.git
repository_type = git
# ... and here

Start the trac daemon and test it works

At this point your trac should be using your git repo for it’s ‘browse code’ section.


$ tracd --port 8000 --auth="*,conf/users.digest,trac" .

You should be able to view the code at http://localhost:8000/mouse-trac/browser. If you see your code (or a message telling you “No changeset HEAD in the repository” if you haven’t pushed your code yet) then congratulations you’ve set git and trac up. The git plugin provides a number of options, but the defaults are pretty sane so I’m sticking with them, if I find any problems/interesting configurations I’ll let you know.

[footnode] Remote Git over SSH

Just a quick, “how do I set-up my client repo” as a friend asked about it. After doing the following from your local git repo, you can just use “git push” to push to your remote server (trac). The “FlapJack” is the name of the VM I host my local trac in.


$ git init
# do work ...
$ git commit -am "inital commit"
$ git remote add origin ssh://webpigeon@FlapJack/~/trac/repo.git/
$ git push origin master

Going to http://localhost:8000/mouse-trac/browser should now show you your lovely committed code.
For additional commiters/computers you can then use:


$ git clone ssh://webpigeon@FlapJack/~/trac/repo.git/

If I’ve missed anything or something doesn’t work let me know in the comments and I’ll fix it. Hope this helps.

Emailing Git Commits

Did you know you can use Git to submit patches to projects via email (or website)? Thanks to Bruce I not only found this out but I also found out how to merge the patches as well. In this post I’m going to show you how to do it. There are quite a few uses for this, for example you might want to use this method for submitting patches to a bug tracker or to allow someone to contribute without giving them direct commit access to the repository.

Firstly you’ll need to grab yourself a copy of the repo for the project you want to write a patch for. This is a pretty standard thing to do.

$ git clone git://github.com/schacon/simplegit.git

Next you make your changes and commit them to your repository, again something standard for git users.

$ git commit -am "added foo to component bar"

Now the interesting bit, we’re going to generate a series of patch files we can send to the owner of the repository. The following command will take all commits which are not in origin (the place you got the repo from), with one commit per file.

$ git format-patch

You can then attach these patch files to a bug tracker, email or whatever you like using a version control. There is also a git command to send email but I’ve never used it so I can’t comment on it’s use. It’s git-send-email.

On the other side of equation there is merging of the patches. There are multiple ways to do this and a few useful commands related to it. The first command tells you how much how much the patch changes. Check checks if the patch can be applied cleanly. If the patch can be applied then you can use either ‘git apply’ or ‘git am’ to apply the patch.

If you use git am you can supply –signoff to let people know that the patch is approved. You can also supply -3 if the patch fails it will allow you to merge changes and use git  am  –resolved to mark the merge as resolved.

$ git apply --stat my_patch.patch
$ git apply --check my_patch.patch
$ git am -3 --signoff < my_patch.patch 
$ git am --resolved # if the patch needs merging to take place

Installing Trac (with Git) in Fedora 15 [part 1]

Okay, all the documentation I found was hideously out of date. I needed this for my final year project (keeping track of my project in trac) and so here is how to install and setup trac in Fedora.

$ su -#yum install trac trac-git-plugin

This will install (but not setup in any way) trac and the trac git plugin. Next you need to change directory (or make a directory) where you would like your new trac instance to be stored.

$cd /home/webpigeon
$mkdir trac
$cd trac

Now we run trac-admin to create our trac instance. This will then be used for running our trac server. We’ll then launch the trac instance and check if it’s accessible on the web (by going to localhost:8000)

$ trac-admin /home/webpigeon/trac initenv
$ tracd -s –port 8000 /home/webpigeon/trac

Going onto localhost:8000, you should now see your shiny new trac instance is running. We now have a trac instance we can run (sort of) it’s still using svn and it will moan about not having any accounts if you try to use it.

Interestingly, trac doesn’t actually manage it’s own user accounts… it lets the web server do that for it (http authentication). As we’re going to be using tracd rather than apache to run this (it’s only a small project after all) we’ll have create some accounts and tell trac about them.

I’ve got the apache packages installed even though I’m not using apache, so I have access to the apache “htdigest” command. This allows us to create accounts in a format that trac will understand (http digest). I’m putting my users file in conf/users.digest because that’s the recommended place to put it, but you can put it anywhere. The command accepts a ‘-c’ flag, which will create the file. You can then add as many users as you want by calling the command without the ‘-c’ flag. Each time you run the command it will ask you what you want the users password to be.

We’ll then use trac-admin to give a user admin rights, which will allow them to manage the website from the front-end (so I’m told – I’ve haven’t played with that yet). You can also manage trac from the command line using trac-admin directly (how I’ve been doing it).

$ htdigest -c /home/webpigeon/trac/conf/users.digest trac webpigeon
$ htdigest /home/webpigeon/trac/conf/users.digest trac battwa
$ trac-admin /home/webpigeon/trac permission add webpigeon TRAC_ADMIN

Now we have some user accounts, we can start tracd and tell it about the password file. The syntax for this is a little odd. From what I can figure out the first part is the trac instance you want the passwords to be for, as I’m not that fussed I’ve said all of them using a ‘*’. The second part is where the file is stored and the 3rd part is the authentication realm, I’ve just set this as “trac”.

$ cd /home/webpigeon/trac
$ tracd –port 8000 –auth=”*,config/users.digest,trac” /home/webpigeon/trac

You now have a working trac instance with SVN. I’ll publish the stuff regarding how to get git working later. This is a long enough post already. EDIT I’ve amended the post with corrections mentioned by isorfir in the comments.

Fedora Development Packages

Hello,

I have just got my new machine and I’ve been setting it up for development. However I couldn’t remember any of the package names. So as a future reference for me (and anyone else who needs it).

$ su –
# yum install git
# yum groupinstall development-tools
# yum groupinstall development-libs

and from bruce cowan (bruce89) – for gtk3 libraries
# yum install “pkgconfig(gtk+-3.0)”

This installs all kinds of tools, including gcc, doxygen, make and g++. All 4 of which I use and also installs most of the development tools I could ever want for low level code development. The development-libs contains lots of useful libraries which I’ll never probably use but they’re useful anyway (especially when compiling other people’s code).