Alain M. Lafon

Ever since I evaluated and implemented project management software for my current employer, I have been a big fan of trac. While I knew about the downsides of svn, I liked the upsides of trac: it’s lean, it’s clean, it’s Python!

During the last year, however, I came to realize that even though trac is a great tool for many projects, it might not be best for my personal projects. For one, social visibility is close to zero – in part because I like to host on my own server. Second, I was wrong to think svn is good enough for smaller projects – even when working alone git has major benefits. If only for being able to work offline, worry free distributed backups and beyond human speed. Anyway, “good enough” sometimes is just a fancy argument for being lazy.

So, last week I finally decided to get over it and to try github and git as my SCM toolset of choice. To use github is a no-brainer these days – just about every day I read great stories on HackerNews or reddit/r/programming. It’s not just about free hosting, that’s not a real problem anyway. It’s all about social visibility these days. Not having a github link on your CV will lead to certain questions.

Being on the wrong end of this discussion can be unnerving. It’s not that I can’t defend my point of view. It’s because everyone asking me about it has been right. After having worked with github/git the last couple of days, I conclude those tools have become mainstream for a good reason.

I’m a strong advocate of kaizen – to always improve yourself a little bit. I also encourage people to not only use the tools they know, but to always seek out for the best tool for a new job. I now have to realize, that concerning SCM it was me who had the outdated mindset. trac certainly is a great tool, I won’t deny that. But there is space for improvement. Time to move on.

Turns out, I’m a pretty active coder in my spare time. I worked on four projects the last few days, three of them visible on my new github account. Just smallish hacks, but hell – that’s what I love about coding: always being able to tackle new problems quickly and upfront; it is not about the big bucks – those are a side-effect.

There is no automated way of moving tracker items in GForge. Each item has to be moved by hand. I just wrote an iMacros script to automate this task, which has saved me and a friend a whole day of clicking repetitively.

You can find this script on github: https://github.com/preek/gforge-mass-move-tracker-items

Why we needed this: When you implement a new custom workflow in a legacy GForge environment, it is best to do so in a template. Every new project can then be cloned from it.

Unfortunately old projects will not get updated. You have two choices now: One is to repeat enforcing the workflow on every project (which is a tedious task and can easily take up to a day). The other is to make a new tracker which is cloned from the template. Then you can move your tracker items from the old tracker to the new one. Voila, you got the new workflow rules applied.