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.
I was happy…
- I could work with branches
- I could version source code “over HTTPS”.
- I could view file versions over HTTPS.
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.
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.
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.