Search This Blog

Posts

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…

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).

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 ImmobilienScout24.de. It was a fascinating talk, with lots of insight into a real,…

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.

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…

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.

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…