git <-> svn

You may guess now I like working with git. I am always amazed how easily I can match the abilities of this software with the several, often changing needs that arise during my work or hobbies. Oh right, it cannot help in skating faster...
And then there is Subversion. I should not say I hate it but I think it is a slow dinosaur, ugly, fat and slow-moving. But still, many projects use it so if you want to participate in them, you've got to follow the flow.
And there comes git-svn to the rescue. It enables you to use your beloved git in a subversion-based project easily. This is how I've set up my workplace for Speed Dreams development, using git for effective feature branching, mergeing, rebasing and such git candy:

mkdir sd

git svn init https://speed-dreams.svn.sourceforge.net/svnroot/speed-dreams/trunk

git svn fetch -r3096 (of course you can choose another SVN revision)

git svn rebase

and voila you have a nice and shiney git repository that mimics the SVN repo.
Anytime you want to update your repo (like doing 'svn up'), just issue

git svn rebase

The above process is explained in more detail here (thanks, Flavio), along another entry here.

Now onto feature branching:

I quite like the Story branch pattern, so basically what I do is:

1) Find a ticket to work on in the Speed Dreams Trac system, let's say it is ticket #100.

2) git co -b 100_ticket_short_title this creates and switched to a new git branch that I will use for this ticket only

3) hack this & that

4) git add -p

5) git ci -m 'Commit message that really tells something. Re #100' - so I always try to include the ticket number in the commit message, good for Trac coverage.

reiterate 3-4-5 until ticket is finished

6) git diff --cached (review all the work done)

7) git rebase -i HEAD^8 (or so, view last 8 commits and squash them together if needed - this to get rid of the side effects of very frequent git commits)

Now before committing to SVN let's make sure it won't cause any conflicts:

8) git svn fetch && git svn rebase (OK maybe git svn fetch isn't needed)

If still 'green', then commit to SVN:

9) git svn dcommit

Now switch back to the master branch and update it, too:

git co master

git svn rebase

Set the ticket status fixed and delete the branch, if you like. I prefer to keep it around for some weeks in case the ticket is reopened after the initial tests, but you can get rid of it or create a new branch then - really just a question of taste.

The only thing you should really take note is: you cannot do a git svn rebase if you have any uncommitted changes. Fabio's blog says he uses git stash to put away his changes, does the rebase, then does git stash apply to get his changes back. I prefer to commit my changes instead, do the rebase and then work on the usual way. Which one you choose is up to your taste - both approaches work fine.

This is the real git magic - you can choose the way you work!

Ramblings - 2010/43

Remember last time I wrote that I can run Speed Dreams again with decent FPS? Well, that seems to get worse now, the driver fails quite often and SD exits then. Another Linux bug, got to check the reports :(

Yet I've managed to develop the robot some more. Now it can handle skill settings, so you can set it up to be hmmm 'less than perfect'. The setting affects the braking (it starts breaking for a turn earlier), accelerating (it accelerates slower) and the width of the track is uses, so it isn't so brave using the full width of the track and sometimes even more, remains on the 'safe side' of driving. Whether this skilling is consistent or not, ie when skill is lower by 10% the lap times get worse also by 10% is subject to further testing.
Now I am in the process of setting up the LS-GT1 carset for the robot, the first car (the Archer R9s) is kinda ready with two fictional drivers. Check the process details here.
In the meanwhile I am trying to adapt the coding style of the whole robot codebase to match that of Google's advised C++ coding style. While in some moments it seems to be too narrow-minded pedantric there is quite some thought in it and in the end it may help improve code quality. One of the changes was to use full path in includes, #include "src/drivers/kilo2008/pit.h" instead of #include "pit.h". Kristof reported it caused problems when building the code but I think it is rightful to be sure the compiler uses the correct header files in situation like ours when there are several robots in the source tree with a pit header. Later Kristof said it only caused problems when using a separate build directory so not in normal cases. Another suggestion was to use "using ::std::string;" instead of "using namespace std;" so not to pollute the global namespace, something I've never ever thought of but can see the reason behind. cpplint.py is a great tool helping this process (nah in reality is a nasty little !*@#**^%& but we love it, right?)

Track-wise I am fighting a pitlane issue of too wide a pit lane and matching the correct texture for it. Just look at sat pictures of the St. Petersburg GP and you'll see my problem. Oh damn, I've so many track ideas... and Knockhill is next on the door.

The other day I've ticked off a ticket about incorrect number of laps displayed in the board1 area that was caused by such a trivial error I didn't notice it for an hour or so... passing the address of a char array to a function, then checking it's size is snprintf, the size if not the array size but the size of the pointer hahaha (4 vs 255). Trivial but painful :)

Haruna has shot a nice video of the current state of Speed Dreams, it is on Youtube, check it out:

That's all that comes to my mind today, Halloweeeen is right here \o/