fjellstad.org

I recently moved all my development over to a distributed version control system (dvcs) called git. I’m not going to write about dvcs and the difference/advantage/disadvantage between it and central version control systems, like Subversion. There several good articles and blogs on that topic around already [1][2][3]. This is more about my journey.

I started my (development) career using SCCS and RCS slowly moving towards CVS. They worked, with some warts. Some of the weaknesses are well-known, but for tracking individual files, they work really well, and I still use it. Once Subversion came on the scene and stabilized (with the introduction of fsfs repository type), I was hooked. One of the thing I really liked was the concept of change set, that is set of changes that logically belongs together. Like say, a header file and the source file. Change the header file and the source file needs to be changed too.

I recently got in trouble with my svn repository when my working set got into an invalid state as far as my repository was concerned. What happened was, when I moved back to Norway, I shipped my computers. I had made a backup, but had continued developing. And the shipping had taken time, so I had created a new repository from my backup. But since my working set was at a different version than my backup repository, svn wouldn’t let me checkin. Frustrated, I started looking at other vcs.

What got me first looking at git was the google talk by Linus Torvalds. I then read up at the current state of dvcs before I started testing out git, and I was hooked.

What I find interesting is that git feels ‘natural’. The impact on my development process is minimal. As an example, to create a tag in svn:

svn copy svn+ssh://server/path/to/project/trunk svn+ssh://server/path/to/project/tag/{version}

The same command in git:

git tag {version}

Branching is similarly easy in git. But I think the main advantage is that I now can I have multiple repositories for the same project.

My current work process is like this:
edit edit edit
checkin into local repository
edit edit edit
checkin into local repository
happy state
push to private server
edit edit …
once stable state
push to public repository

At at any time during the editing phase, if I’m unhappy with the track I’m on, I can always throw out the changes without messing up my private or public repository.

I really think you should at least take another look at the dvcs and see if it’s something for you.

[1] Wincent Colaiuta’s development blog
[2] Dave Dribin’s Choosing a Distributed Version Control System
[3] Ben Collins-Sussman’s The Risks of Distributed Version Control