Monthly Archives: January 2010

Fixing metrics in phpUnderControl 0.5.0

I recently upgraded our buildbox to phpUnderControl 0.5.0 being really curious about new CodeBrowser feature. And indeed CodeBrowser addon is really cool (see Manuel Pichler announcement on his site for details), but after the upgrade I found Metrics tab broken. Instead of nice shiny graphs it showed me Java exception like this:

Metrics exception

Metrics exception

It took me a while to figure out what caused this strange behaviour. I have found the answer when I have run graph generation manually:

#> phpuc graph logs/PHPUnit-3.5/ artifacts/PHPUnit-3.5/

It returned pretty instantly the following error:

The value '1' that you were trying to assign to setting 'labelCount' is invalid. Allowed values are: int > 1.

A little bit of googling and I actually found the answer, again on Manuel Pichler site, in the comments for the announcement.

Basically with phpUnderControl 0.5.0 a file has been released called ClassComplexityInput.php. It is not ready yet to generate a graphs (I suspect it’s gonna be a graph representing class complexity), but phpUnderControl goes through all available input processors to generate graphs for the metrics page.

Fix in that case is pretty trivial, just remove the file (it’s in phpUnderControl/Graph/Input/ directory) and voila – your graphs are back!

Metrics fixed

Metrics fixed

Sharing your git repository

… or maybe not.

We’ve had this problem for some time and couldn’t really find a good solution for that. We wanted to have some repositories to be only writeable for selected users and even some repositories to be accessible for some users and completely invisible for the others.

First requirement seemed to be pretty simple as git access control is based on file permissions. So creating a repository only writeable for a selected group seemed to work… until somebody hasn’t committed a change which created a new object in .git directory which wasn’t group writable! The next person trying to change this object after was getting permission denied error like that:

#> git push origin master
Counting objects: 5, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 286 bytes, done.
Total 3 (delta 2), reused 0 (delta 0)
fatal: failed to write object
error: unpack failed: unpack-objects abnormal exit
 ! [remote rejected] master -> master (n/a (unpacker error))
error: failed to push some refs to ''

Obviously git atomic commits did its trick and didn’t break the repository, but at the same time this issue prevented us pushing the changes to remote repository! We had tried different git hooks, but it didn’t work the way we wanted. So basically we ended up with a script that must have been run manually on git server when the issue was encountered.

if [ $# -lt 1 ]; then
    echo "Usage: $0 <repo>"
    exit 1
chown -R owner:group /path/to/repo/$1.git/objects
chmod -R g+w /path/to/repo/$1.git/objects

Until now. Friend of mine (thanks rodrigez) actually discovered a native git feature, that allows you to control access to a repository – core.sharedRepository. It accepts the following values:

  • umask (or false) – the default value. Git uses permissions reported by umask
  • group (or true) – makes the repository group-writable
  • all (or world or everybody) – same as group, but make the repository readable by all users
  • 0xxx: 0xxx is an octal number and each file will have mode 0xxx. 0xxx will override users umask value. 0640 will create a repository which is group-readable but not writable. 0660 is equivalent to group.

You can set that using either git config command if your repository already exists, or you want to make the default value either global or system wide:

#> git config core.sharedRepository group

or during brand new repository creation:

#> git init --shared=group

So for me setting core.sharedRepository to group solves my first issues, while removing all access to other users to all files in the repository and setting core.sharedRepository to 0770 will restrict access to the repository to only limited number of people.

Git Up and Get Going

I have used git for the first time about a year ago. We’ve been talking about abandoning CVS for quite a while and Subversion seemed to be the best choice at the time. Yes we’ve looked at different version control systems, we tried sample migrations and still we couldn’t make a decision. And CVS… it was a constant battle, continuos corruptions, old hardware, hours long merges, but  it worked, so the general response was – why to change something that works.

We needed a strong kick in our butt and fortunately there was a man that was brave enough to kick until it hurt (thanks Rys!). With management convinced we only needed to plan the migration, schedule the training and just start using it.

That was about a year ago. Now, we use it on a daily basis, and I can’t imagine how we could live without it before. Yes, it’s not as mature as Subversion, Windows tool are poor and far from ideal, but it definitely speeded up our development process. I remember all this scepticism at the time and I only bring it up now because in the past few weeks I have actually seen more and more developers and projects switching to git. I was really glad to see PHPUnit and phpUnderControl moving over to github. It makes contribution to these projects so much easier.

I think git is the future of the open source software and it makes its development so much easier and faster. So if you haven’t used it yet or you’re just simply afraid of it, please put your fears aside and git up and going!