Git is not Subversion

We decided in Spring 2011 to take Git in use as our only version control system. Original ambitious goal was to get rid of all existing Subversion and CVS repositories by the end of year 2012. That didn’t quite work out, we still have a lot of stuff in the old repositories. I can understand this with old not active repositories where nobody sees added value in moving them to Git, but a lot of active development is still done in Subversion repositories.

We’ve had several debates over the issue, latest was today. Some developers were complaining that Git is too complex, it is too difficult to learn to use correctly and it doesn’t explain what went wrong clearly enough. “With Subversion things are just a lot simpler and easier.” When digging deeper with this I found out some of the (Windows) developers are trying to use Git as they have used Subversion. So no use of local branches, no use of stashing, no use of rebasing… And they don’t want to use Git command-line, but GUI tools instead. Because that’s how they have always done.

I admit, if you use Git like you would use Subversion, Git is worse. It sucks. And if you don’t familiarize the fundamentals of distributed version control, Git will never be easy for you. It becomes the necessary evil of version control and you will never learn to use it properly. You start to hate it. And you won’t do anything in order to move ye old Subversion repositories to Git.

Git is not Subversion. Git is a distributed version control system and fundamentally different from Subversion, CVS or (dear god almighty) Source Safe. In order to properly learn Git, one should forget everything they’ve learned from source code version controlling using Subversion or CVS. Git is different. Even though it can be used like you would use Subversion, it is not meant for that. It is a powerful and sophisticated tool which helps you version control exactly the stuff you want. Git is your friend.

So give it another try, but this time start fresh. And uninstall that GUI tool or at least forget it. Git should be first learned using the command line version, it’s the best way to learn the usage properly.

Internet is full of resources for learning Git. Here’s for example one I presented in the Tampere Goes Agile conference in 2011: Up to speed with Git.


Return of the Son of the Farewell to SVN

It’s almost a year since we started piloting GitHub:FI in our company. I had high hopes that by the end of 2011 everyone would be already using it. Or at least most of the people. Didn’t happen. Latest ambiguous estimate is that we could maybe get rid of most of the SVN (and CVS!) repositories by the end of this year.

We deliberately started piloting slowly and expected people to start taking GitHub in use after piloting phase was over. Didn’t happen. Those people who already had used Git earlier, were happy to start using GitHub. Several of them had already been using Git on another server… We managed to also mandate new development projects to start on Git instead of SVN and that worked reasonably well, but. Several projects were continuation of previous incarnations of same stuff, it’s anyway rare that something totally new is started. And as people were busy and projects on a tight schedule, no PdO wanted to include stories about moving repositories to Git.

Few teams spent their improvement allocation in moving the repositories to Git and started then learning new ways of working. Some hick-ups were experienced as well as some resistance from the SVN–ain’t-broken-no-need-to-fix-it -people. And yet, we’re still in the phase were few of the larger projects don’t have time and/or will to move those goddamn repositories away from SVN to a better place… And yet, using SVN hurts – it hurts every day, but apparently not enough.

I think I’m going to deliberately make all SVN related problems really visible.

And I think I’m going to try to sneak in stories about moving some repositories to Git when ever I have a chance. The battle is not over yet, it hasn’t even really started yet.

But this battle will be won. And it won’t take another year, I promise.

Farewell SVN, part II

We have one team which has been using Git for several years already. When they heard we’re looking for a substitution to Subversion, and speciall when they heard that one of the alternatives is VisualSVN, they said that Git is pretty much the only sensible choice. They did not want to give up using Git. So I started looking for more information about this wonderful VCS. The more I read about Git, the more convinced I was that this is the future choice of ours.

There were few challenges still to be resolved. How to manage access rights? How to manage storing SSH keys on server? How to deal with subcontractors? All the same challenges we had with SVN wouldn’t go away on their own with Git.

That’s when I was introduced to GitHub. A colleague of mine told that GitHub pretty much has everything we’ve been longing for (see part I), it comes out-of-the-box with features supporting using subcontractors and it has some really nice “social” features (see Crappy thing was that our company policies don’t allow storing source code on any other than our own servers. So GitHub was out of the question, it seemed.

Luckily enough, I learned that there’s a concept called GitHub:Firewall. And it’s exactly what we needed and wanted – a private installation of GitHub on our own server, behind our own firewall. Excellent!

As of writing, we’re in the process of taking our own GitHub:FI in use. We’ve got a dozen developers using it at the moment and will expand to whole corporation use during Q2 (hopefully). I really hope that before the end of this year, we no longer have any single SVN installations running (not to even mention about those few CVSes we still have!).

So farewell SVN, I won’t be missing you.

Farewell SVN, part I

During the 13-14 years I’ve worked as a developer, I’ve been storing the source code to various different systems. In the first company I worked in there was no version control software whatsoever. All source code was mostly on developers’ workstations and was synchronized on a network drive on irregular basis. Needless to say, that was the worst way of working this far.

On year 2000 I changed workplace. The new company I worked in was light-years ahead in what came to software development practices. They had a development process! And a coding guideline! And, imagine this, a version control system for storing the source code!!!

The VCS we used at that time was Microsoft Visual SourceSafe, I think it was version 5. VSS kinda worked, but we had numerous problems with it, worst problem being unstableness. The system was offline about once a week as the database needed to be re-indexed or something. Occasionally we lost some data and there were no good tools available to e.g. solve merge conflicts.

It was a big step forward as we moved to CVS. That was the first time we started to outline a central build server. Move from VSS to CVS was a big change and it took a long time until we could retire the old VSS server. It wasn’t long after that when some teams started to move to SVN. Move from CVS to SVN was painless and quick, although we still have some legacy source code stored in CVS.

SVN has worked for us fairly well, but now after running a multi-team project where lots of people handle same source code daily, we’ve reached the point where SVN cannot cope with our requirements.

Also we’ve noticed that we have way too many SVN repositories and even few old CVS repos. So we’ve set a couple of goals for the new VCS:
1. We must be able to store all source code on the same system
2. VCS must support our way of working with multiple scrum teams
3. R&D, instead of IT, must be able to control access to different parts of the source code.
4. Transition process must be as easy and painless as possible

So the hunt for A Better VCS(tm) had begun.