Skip to main content


Showing posts from 2010

Git-SVN Mirror for multiple branches

This post is part of a series on Git and Subversion. To see all the related posts, screencasts and other resources, please click here

This extends the posts where I explained how to set up a git-svn mirror for a single directory.

NOTE: If you just want to use Git against a SVN repo on your own, stop reading ,now, and stick to the git-svn basics. However, if you want a setup where you can share a Git repository with colleagues and friends while still interfacing with Subversion, keep reading.

I'll show how to set up a git-svn mirror for a standard Subversion project with trunk, branches and tags. It's a bit like the single directory mirror, but in order to keep all branches in sync, it's a bit more fiddling. The good part is that this setup enables us to cherry-pick commits from one branch to the other. This is slightly smoother than using svn merge.

First of all, let's repeat how our Subversion and Git-repositories look physically (roughly the same as in previous pos…

Repeating Agile in a Year at CologneJUG next week

Next Monday I'm doing the Agile in a Year talk for the Java User Group in Cologne (JUGCologne).

Unfortunately, the the Xing event is already booked out, but for those who'll miss out, there's always the video recording of the last time I did the talk at FrOSCon.

Oliver Gierke will be presenting Hades afterwards. Should be good stuff. He held a great presentation right after me at GearConf. His topic (Eclipse Mylyn) was more soft, while mine was very techy. This time we've switched around :)

Geek and Poke versus Subversion

I noticed that Geek and Poke has done a fair share of SVN-bashing over the last months. These are awesome, hilarious, and ring so true to my experience with SVN.  I've collected them here and written a few thoughts on how it's different with a distributed alternative like Git.

1. Being a Coder Made Easy
Typical syndrome of first-man-to-the-mill syndrome. The typical use-case is to commit a big fat refactoring early in the morning, before anyone has a chance to get in your way.

With Git, these situations do not occur so often. Big commits are made in branches where they do not disturb the workflow of others. Branches do have to get merged back at some point, and conflicts dealt with, but this happens in a planned and orderly fashion. There is no race to merge branch first.

2. Simply Explained - SVN Guinea Pig
Oh, so typical. Do not update the code when it's broken centrally. This problem is magnified in the lack of a continuous integration system or a fast build.
With Git, your…

Pumping blog traffic with DZone, etc.

This is microscopic blog, readership-wise. Since I started tracking traffic in June 2006, there's been 15,514 visits. Each blog entry usually gets around 100-300 views, with a few odd cases booming into the thousands, like my Spring TestContext post with 2,378 views and counting. The thing that made that post so popular was that it got 'DZoned', and is still the 3rd result on Google on the subject to this very day.

By any standard of the Internet, my blog is tiny, but I don't mind, cause for me it's just my voice in this "tribe" of these 300 like-minded people, typically Java-enthusiasts with a sense of agile in them. Many of them are old friends and colleagues, and some are new people that I sometimes meet at user-groups and conferences. The blog is part of my dialog with them, just like with my twitter account (number of followers is also right under 300).

Recently, I devoted quite a few evenings putting together my first ever screencasts, on the topic …

GearConf 2010 impressions

This week, me and a couple of colleagues attended GearConf 2010 in Düsseldorf. I also did a talk there about Git+SVN. Figured I'd write a couple of impressions from the conference.

First of all, there aren't enough conferences around here aimed at our profession. There must be tens of thousands of people working with software- and IT in NRW, and this amount of people deserve a bigger community scene than a few JUGs.

GearConf is a great event in this landscape. Obviously, it's a lot about gear, tools we use for software development. It's also language agnostic, so there are talks about .Net and Java and others as well. Finally, this year attracted many talks about agile practices, like Scrum and Kanban, and specific agile techniques.

Day one
On day one, we started off by attending the "Agile refactoring" talk by André Neubauer (@devpg) and Oliver Schmitz-Hennemann (@oschmi), from It was a fascinating talk, with lots of insight into a real,…

Git+SVN #7: Leaving SVN behind

This post is part of a series on Git and Subversion. To see all the related posts, screencasts and other resources, please click here.

This is my last Git+SVN screencast for the time being. Appropriately, it's about the steps we can take when leaving Subversion behind forever, allowing us to fully make use of Git.

We are yet to do this at our place. We will still maintain the Git+SVN bridge until the majority of the developers have been persuaded into using Git as an "SVN client". And in case Mercurial starts to show off some more impressive SVN-integration, we might drop Git in favor of that.

Credit to Thomas Rast who helped me out on the #git IRC channel some time ago. This article of his covers the technicalities of the last screencasts much better than I could explain in the video.

All videos can be viewed on this YouTube playlist, and all content is linked together on my Git+SVN page on Thanks for watching!

Git+SVN #6: Grafting together SVN history

This post is part of a series on Git and Subversion. To see all the related posts, screencasts and other resources, please click here.

Time to whip out the last two screencasts for this round. Here's the first of the two, hopefully the second one will be out later this evening.

Depending on the complexity of the history of your own Subversion projects, undertaking this kind of "archeology" might seem intimidating. At work, we have a rather large SVN project which has been thrown around different locations, split into 30 projects, merged back together again, and moved again on a regular basis. I once began digging through this to get all history into Git, but gave up after two modules. It simply wasn't worth it before we're ready to do a complete migration (leaving SVN behind, which is the topic of the next screencast). 

So, for now, I haven't got the *entire* SVN history in the Git repository. But it doesn't matter, I can still work productively with Git, a…

Git+SVN #5: Centralized Git-SVN Mirror

This post is part of a series on Git and Subversion. To see all the related posts, screencasts and other resources, please click here

Another episode on how to live with Git and Subversion in parallel:

Only a few days left till GearConf, where I will be repeating the exercise, adding all sorts of useful hints and tips on the way.

NOTE: At the end of the cast, I presented this little shell-script that I normally use for committing:

git update-ref refs/remotes/git-svn refs/remotes/origin/master
git svn dcommit

Some more background:

git svn dcommit actually updates the refs/remotes/git-svn

However, in the case that I first do a git pull from the bare repo, getting the new commits via the "pure" git command, no svn refs are updated! Example:

Let's say bob commits a change. John then updates his repo:

tfnico@flint:~/john/website/>git pull --rebase
remote: Counting objects: 8, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 6 (delta 2), reused 0 (delta 0)

The Worklog aka Diary

This is a pattern I've been applying for the last five years, ever since company wiki became the standard at my workplace. At some point I added it as an agile practice to the Cantara wiki, and named it "The Diary". However, I always end up calling it Worklog in practice. It's a bit of a GTD technique, with some positive side-effects.

Basically, on a day-to-day basis, write down what you're working on in a wiki page.


2010-10-04 - Fix the funky registration bug - Bug tracker id #18355.  -------------- 2010-10-05 - Still the funky registration bug - Jason committed a fix in r8040, but it didn't work. Writing unit-test. ------------- 2010-10-06 - Knowledge meeting - Awesome stuff. Remember to upload the presentation to wiki. - Registration bug - Resolved task. Talked to Jason and product owner, done-deal. -------------

Keep focused
I'm an easily distracted person. I'd be working with something, get side-trekked by a build-break, or a colleague needing ass…

Git+SVN #4: Collaborate with other Git users

This post is part of a series on Git and Subversion. To see all the related posts, screencasts and other resources, please click here

This one explains some more of the physics of syncing repositories between Git and Subversion land.  The big morale is that you can't really work with branches the way they were made in Git. History will have to be linear by the time you want to push back to Subversion, if you don't want to lose history. This basically requires every merge operation to be a rebase instead.

Theoretically, you could do branches between Git collaborators, but it's probably best to not stay so long out in Git before pushing changes back to Subversion, anyway, so the case for doing any useful branches are basically lost.

You can still do local branching for experimenting with some wild refactoring, or just for sorting different working sets of your code (I do this a lot, in fact). But as long as it's going back to Subversion, it'll have to be straighten…

Git+SVN Screencasts

This post is part of a series on Git and Subversion. To see all the related posts, screencasts and other resources, please click here

In preparations for presenting "Living with Git and Subversion in parallel" at GearConf in a few weeks, I've been practicing a Git+SVN exercise, going through all the steps from Git-cloning a Subversion repo, to full centralized Git-SVN mirror.

While I was doing this, I figured I might as well make some more use of this, and record some screencasts as I go along. I've just posted the first three on YouTube, and collected all my various works on Git and Subversion on this page.

Feedback is much appreciated!

Update: I'll try embedding the videos here on the blog too:

Git+SVN #1: Cloning a repo

Git+SVN #2: Some commits back and forth

Git+SVN #3: Conflicts

Links of the Week

Some time ago, Ole Morten tried a concept called MyWeeklyLinks, but he stopped after the eighth one. I speculate this was because he defined an audience that had no need for this kind of information, namely us: his readership. We rely on Twitter, blogs and other community-driven sites (Digg, Google Reader, DZone) for the fitting stream of links we consume.

That's not to say that that weekly links is a useless practice. Remember that you, dear readers,  are "information power users": We like to stay on top of what's going on out there, we stay updated. We devote a certain amount of time for this activity. Perhaps we have no need to consume "weekly links", but we can produce it for our colleagues.

I wrote my first mail like this to the team mailing list little over a year ago, simply three links:

Hi folks, I just wanted so share some interesting resources I found the last few days:  This is a short overview of some Java programming styles that can give nicer c…

Visualizing Code Aesthetics

In the newest Javamagazin, there's an article by Bastian Helfert and Steffen Hohn about CodeCity, a really interesting tool for visualizing code.

I just ran it over our 300k LOC Java project, and got this model (click to see larger version):

Buildings are classes. Height is based on class LOCBuilding ground-area is based on number of attributesCity blocks are packages. If you actually run the program, you can interact with the model, fly around, click to see which package is which block, etc.

This is all fun and cool-looking, but does it have any practical usage, I wonder?

I think we want to work in small friendly villages, where most houses are evenly-sized, nicely sized neighborhoods, no big ugly gray parking lots, and no towering sky-scrapers.

Here I ran it again on a smaller, nicer project:
Certainly a lot easier to find your way around this neighborhood.

I know Michael Feathers has made quite a few thoughts around code aesthetics. Perhaps these kind of metrics need some more a…

Speaking at GearConf 2010

After tirelessly blogging about how to work with Git and Subversion in parallel for some time now, I fired off an abstract to GearConf, as this looked like a subject that would be right up their alley (they had talks about Git and Mercurial last year). They accepted the talk a couple of days ago, so it looks like I'll be driving up to Düsseldorf on the 11-12. October.

Interestingly enough, GearConf is sharing the event with the Atlassian Software Conference Düsseldorf,. I've been up close and personal with their products before, so it'll be cool to see how far they've gotten since back in the day (when their products were already awesome).

For anyone in the area, the people behind GearConf are also arranging WebAppDays in Düsseldorf from 27-28. September. I would go there too, but I think I'm all out of conf-days for this year :)

How to Kick Off some knowledge meetings

I've gotten some questions about Knowledge Meetings after I presented them as one of our agile practices at FrOSCon some weeks ago. Here are some more ideas/thoughts on how to do them:
What are they? One hour every week. Gather the whole team together, and learn something.
What should we learn about? Anything that will be of interest to your team, work-related. Some examples: This new open source library/project/technology we (can) useNew programming languageThis cool testing techniqueA certain module of the business applicationThe hardware architecture of our data-centersSome applied computer science (algorithms and stuff) What is the concrete contents of a Knowledge Meeting? Anything that'll make you learn. Examples: 10 minute lightning talks/ignitesCoding Katas, or RandorisLonger presentations (try to not go over 30 minutes)Lots of discussions!Lots of live coding! Remember: Let people present the things they already know, but..Give people time to prepare their presentations (1 hour p…

Agile in a Year - Video available

You can now find the recording of the talk on the page for the Agile-in-a-Year presentation.

Note that it's missing the first few minutes with intro, but that wasn't so interesting anyhow, I'm sure regular readers know most of the background.

There's about 40 minutes of me talking, and 20 minutes of questions and discussion in the end. Sorry for not being so good at repeating your questions into the mike!

Why Distributed Revision Control increases Agility

I recently did a talk about practices we have introduced to make us more agile.

At the end of the presentation, I mentioned distributed revision control as one of the next practices we want to do. Now how on earth does using Git or Mercurial increase our agility?

The short answer is: Feature Branches.

The long answer is...

We have a defined agile as among other things, this value: Ship working software.

This value implies that we keep the mainline of the code (known to many as the stable branch) in a working state. A good way to keep it that way is by making sure that only safe changes make it into the mainline. If you've got developers continuously working on the mainline to create new features piece by piece, chances are the code is in a broken state every now and then.

In order to remedy this, lots of companies (including ours) have decided that the team should maintain two versions:

one experimental, where new features are developed, and one stable, which should always be in a w…

Agile in a Year @ FroSCOn 2010

Just a few hour ago, I did a talk called Agile in a Year at FrOSCOn 2010. Great conference, as it was last year. Hopefully going back tomorrow for day 2!

I've put the "slides" and references from the talk on my homepage.

Hopefully, a recorded video of the talk will be online soon. Unfortunately, I botched it a bit by forgetting to put on the microphone at first, but got it on about 5 minutes into the talk. Will post back here when the video is ready.

And if you were in the audience: Thank you so much! Full house, great discussion and questions afterwards.

Git and Subversion summary

This post is part of a series on Git and Subversion. To see all the related posts, screencasts and other resources, please click here

This post is part of a (slightly chaotic) series on Git + Subversion. Unfortunately, due to my problem with editing posts in Blogger, they've ended up a bit scattered and poorly organized. So here's a summary of the posts with more fitting titles:

A big rough introduction to distributed source control and GitWhy and how clone of a Subversion repo into a Git repo (aka SVN mirror)Sharing a Git SVN mirror in a teamSharing a Git SVN mirror in a team clarificationsSo, if you just want to get into using Git, take a look at 1. If you want to port an existing Subversion repo, 2nd post is the thing. The 3rd and 4th are for those of you who need to stick with Subversion for a while longer. The illustration below illustrates an example workflow for the last case.

Ref GitFaq. Note that devs *might* have to run update-refs before running dcommit back to Subv…

Some clarifications on living with Git and SVN

This post is part of a series on Git and Subversion. To see all the related posts, screencasts and other resources, please click here

I'm afraid I exaggerated in my previousposts, and given the impression that living with Git and Subversion in parallel is easy. I would update it, but Blogger is refusing to edit the post without screwing it up. So here it is in clear text:

Be prepared to face some major constraints in using Git against a Subversion repo, compared to how it using Git standalone.

The manual says it best: The git svn tools are useful if you’re stuck with a Subversion server for now or are otherwise in a development environment that necessitates running a Subversion server. You should consider it crippled Git, however, or you’ll hit issues in translation that may confuse you and your collaborators. To stay out of trouble, try to follow these guidelines:Keep a linear Git history that doesn’t contain merge commits made by git merge. Rebase any work you do outside of your …

Syncing your Git repo with the Subversion repo

This post is part of a series on Git and Subversion. To see all the related posts, screencasts and other resources, please click here

This is a follow-up to the previous post on how to live with Git and Suversion in parallel. It's really trivial stuff for any experienced user, but was worth noting down somewhere for my own sake.

I've cloned a project called "fudge" from Subversion:

>git svn clone

So my local repo has the correct svn-remote configuration and all that to go with it inside fudge/.git/svn. This is done automatically when you svn-clone.

The bad thing is that all my Git-mates at work have to wait for me doing svn-rebase before they can pull the latest code from Subversion from my repo into theirs.

I want to get rid of this responsibility. I'll put something similar to my svn-rebasing repository on a server, have it run svn-rebase regularly, and push the changes to a centralized git repository, that everyone can p…

Presenting at FrOSCon

Next month I'll be presenting my Agile in a Year talk at FrOSCon, a local university-driven conference about open source and related topics. At the moment I'm mashing together the slides (well, strictly speaking I'm not going to use slides) that have to be done by Sunday, so I'll keep this short.

I'll be talking about the agile practices we have introduced at IP Labs, more or less during 2009. Just to be clear: I'm not saying that we "became agile" in this period, but we did become more agile*.

If you are in the vicinity of Bonn/Cologne around the weekend of 21-22th of August, I hope you'll drop by. Visiting the conference will set you back a whopping 5 €.

* Tip o' the hat to Johannes for this idea.