My VCS story began with Microsoft Visual Source Safe.

I was happy…

  • I had my files versioned.
  • I could view differences in file versions.
  • I could restore previous versions.
  • I could view the history of a file.

… until the IDE started to crash, I had corrupted files and so on.

image

http://www.flickr.com/photos/nesster/5823554695/

So I gave CVS and then SVN and TFS a try.

I was happy…

  • I could work with branches
  • I could version source code “over HTTPS”.
  • I could view file versions over HTTPS.

… until I saw a GIT introduction on the .NET Open Space presented by Alexander Groß.

I was shocked about how I had worked before!

He showed that it is not necessary to explicitly check-out and check-in files. I almost all areas of software development we try to align with business and to focus on the features that help or supports users or customers at their processes (E.g.: OOD, DDD, etc…).

So why should I commit a change set just because I want to rename a file a second time? That is not a feature. It’s not even the result of a refactoring. Its just to satisfy the tool.

Here are a few reasons why:

  • Refactoring is an important part of the process to maintain a healthy and high quality code base. It means changing the structure…
  • Naming I one of the hardest disciplines in software development. I don’t thing it helps anybody when there is an additional burden called the check-in. From my experience It holds people back from improving the code.

2010 I moved into the DVCS world. I started with HG and later moved on to GIT.

I am happy…

  • I can focus on the features.
  • The SCM understands branching
  • The SCM understands refactoring
  • The SCM understands merging

Last year on the NRW Conf my friend Ilker Cetinkaya held a lecture about commit messages. In his opinion the commit message should tell a story and answer the questions: What, why & how. He sowed really nice examples of commit messages almost equal to a blog post or a developer diary. Focusing on the Feature (LOB) and providing details about the technical realization. Markdown is an ideal format here. I cannot agree more. After the conference we discussed non-feature-commit-messages and agreed there should just be one: “Rechnerwechsel” the German term for “Switching the Machine”.

When I join a project of a customer I sometimes still see SCM systems that still require explicit check-ins.

My pleading

Let developers focus on the features to deliver better results. Everybody has just 100% to give. Don’t take even a few percent of the developer productivity to hassle with a SCM just for the SCM. Version control exists to support people. Not to change the way people work: The motivation and empowerment of programmers has a direct and strong relationship to the quality of  the software.