Stitched, modularized and converted

Yesterday I decided to finally follow through on a promise I made to my programming team of one person, me. The promise was to get some of the repositories for sub-projects into one bigger one. It makes sense to have all of them in the same repository because they are so dependent on each other. All of those projects are on GIT repositories,  so the logical choice is to use git-stitch-repo and stitch it up. What that little tool does is zip up (like in zipper) several repositories. Every source repository gets stuffed in a sub directory, so it looks clean and nice as well.

After the stitch I had to rename the tags, since all tags got an uppercase letter appended – A for the first repository I wanted to stitch, B for the second, etc. Then I saw that the history wasn’t completely clean. Previously there had been some branches and even a tag that pointed to a deleted branch but still persisted. Checking out that tag and suddenly you’re at no branch! Strange… Luckily it was just a throw-away branch, so I threw it away and went through all source repositories, cleaning them up. Stitched them up again, removed all clutter and what was left is a clean history and a neat directory structure. Awesome!

Some people still have to depend on subversion, since there is no easy and safe way to integrate GIT into Eclipse. I tried, but every once in a while stuff gets messed up for strange reason, no joy. So at one point the stitched needs conversion, but first I modularized the Maven projects it contained. Not that hard, so that took only a few Google searches and some trial and error (first time I ever made a modularized Maven project with parent POM). The result, very nice.

Time to convert to subversion. I used a Perl script called git2svn by Love Hörnquist Åstrand. It does the job well, except that it doesn’t do tags. I guess doing tags is harder or maybe the script wasn’t meant for what I used it for. I will ponder about redoing the convert with a modified script that can add tags or just add tags myself, preferring the former.


Why I like git-svn

By now everybody must have heard of GIT, the distributed version control system (dvcs). Having worked with CVS and Subversion (SVN) I must say that I’m now a huge fan of GIT. Well, maybe it’s better to say that I’m a fan of some of the features I tend to use a lot. Or at least the ones that seem more accessible to me in GIT than they do in SVN.

Granted, switching between branches is something possible in SVN too. A dvcs makes this stuff almost as easy as… well basically it is a short flurry of fingers across your keyboard. In case of GIT it’s:

git co -b branch-name

That command creates and checks out the branch. Now how easy is that? So if I want a new feature I can just make a branch and start working. Branches are also used to clean up deprecated methods and other clutter removed in a future version. So it’s kind of like a glimpse into the future. The only disadvantage is that you have to keep them up to date, which is very time consuming.

Sometimes you’re too busy programming and tend to forget to commit your code. Luckily it’s easy to commit only a chunk or line from your code using git-gui. That way you can still create some order in your commits and avoid the occasional tsunami of code. Smaller chunks are easier to swallow than large ones.

But not everybody wants to use GIT. So compromise is necessary. Which at the moment is a central vcs like Subversion so anybody can access it and then let me have my own little version control paradise island by cloning repositories with GIT.

I found out the hard way it’s easier to work on a clone of a SVN repository than on a clone of a GIT repository that clones a SVN repository. Too much places where stuff will go wrong. Other ways to screw up a perfectly organized system include forgetting which local branch you are working on. There are tools to restructure commits on GIT, but they are difficult to use. Once you structurally make mistakes those tools become routine, but structural mistakes turning into routine is bad.

Once I setup the aliases for certain often used commands with git svn life got easier. Before a commit I issue a svn rebase, for which I created an alias called dmerge. After that my code is back on top. Sometimes I have to manually resolve a conflict, but that’s OK.

In short, I like the way git gives me an extra buffer before I actually commit to the central SVN server on shared projects.