Leaving subversion for git

Posted in tools by elisehuard on February 19, 2010

Let’s be fair, subversion is an honourable version control system, better than CVS and some commercial VCS, and infinitely better than no version control at all.
Still, once you’ve tried git, there’s no going back (or not willingly, anyway). The easy branching, rebase, cherry-pick, stash … did I mention I want to marry git when I grow up ?

Many posts have been written on this subject, so I’ll just link to the ones that helped me, and add some comments where necessary.

svn to git repository

you want your whole history to be available on the git server. Easy to do, as described here. I would advise to do an intermediary step to get rid of all svn references.
Your branches might have names that look like paths. If this bothers you, and you’re still using them, you can create nice links pointing to them by doing

git branch -b  <nicer_name> <bothersome_name>

But: this doesn’t really cover the whole story. Your project might have svn:externals.

  • If these externals are served from outside, you could piston them. Piston now works equally well with subversion and git.
  • If these externals are in-house … well. Use this how-to recursively to also have them into git repositories, and git submodule add. If this is sensitive and touching the external is a no-no, just piston them as well.


I had a look at gitorious, but it doesn’t play well with postgres, and I couldn’t be bothered to install mysql just for this purpose.
So I decided on the simplest tool, which is already included in git: GitWeb. How-to is described here. Basically, if you want to try it out, go to a git repo and do:

git instaweb

if you’ve got lighttpd installed, otherwise add option –httpd=webrick
To serve it with Apache (or Nginx), follow the tutorial above – the ‘make’ step is not actually necessary, the gitweb module apparently detects all git repos on the system.

Update: to view local repositories on your own desktop, you can use gitg or gitk (if on linux) or gitx (if on mac).

There you go, time to git clone and start playing.

Note: as you can see from the links, the Pro Git book is a good reference for things git.

Bye bye mac

Posted in tools by elisehuard on January 12, 2010

macbook pro
For about 2 years I’ve worked on a Macbook Pro. It’s been a mostly pleasant experience – smooth graphical interface, more than adequate hardware – it took a while getting used to, but it worked out OK.

Still, I find myself turning back to Linux for development.


I’m not the most organized person in real life, but I can be fairly anal about my file organization. And I find it quite an effort to keep my Mac’s file structure clean and simple.
First, there is Apple’s own directory structure – apparently they found it necessary to differ from the BSD they’re based on, and use a list of non-standard capitalized (!) directories (Libraries, System etc – have a look at Applications for pete’s sake).

In my work I use a fair number of open source tools. The easiest way to get those on a mac is using macports. Macports installs things in /opt/local by default, so there’s a few things lying around in their own directory structure there.

The macports people do good work, but it’s difficult to keep up with releases, so often you need a newer version of a tool, or you need an extra library that hasn’t been packaged yet. So you compile. If you’re not careful, the compiled items are then installed in the usual linux directory structure (/usr, /usr/lib etc).

Result: something that works, but it can become a disorganized mess, which chafes a bit.
(and don’t get me started on Mac’s very own dynamic libraries and executables)


when I work, I’m mostly using terminals and the command line. Vi is my editor of choice (good vim rails plugins here). So all the nice graphical effects and applications requiring a mouse don’t have much added value.

Friends have introduced me to a great window manager on Linux, coincidentally called Awesome. This is a tiled window manager – which means that most windows don’t float, but are tiled, and make full use of the screen real estate. There are by default 10 desktops, allowing a good organization of windows. Navigation happens through key shortcuts. Shortcut keys, default applications, the whole interface can be customized using Lua. Now tell me that isn’t awesome.

Linux for the desktop

It used to be a pain in the neck to have Linux be completely functional, especially on laptops. I remember poring over hardware manuals looking for chipsets, and endless trawling through forums to get X to work properly. Nowadays installing an ubuntu or a debian is mostly inserting a disk and clicking through an install.
Because you see, it’s not because I can manually partition, hand-compile kernels and libraries, fiddle about with settings, that I want to spend time doing this for my desktop, per se. We’ve all got better things to do. Zack the Mac was a temporary solution to this issue.


Fourth (minor) reason to go back: well, Apple. They have the hardware, they have the software, they make me pay. It feels like being submissive to the fantastic marketing machine Steve Jobs set up.

I like the mac hardware, and Mac OS X is fine for casual use (like watching movies, email, blogging), and of course for iPhone development, so it’s not a definite parting. Might make my MBP a dual boot (I’m told boot camp makes this very easy). Let’s see how this goes !