4 Signs You Are Fighting Your Version Control Tool
Are your habits and procedures at odds with your version control tool?
1. Afraid to delete
Some people don’t like to “delete” other people’s code. When they fix a bug, they’ll comment-out snippets of bad code, add their bug fix, and commit both. Over time these commented-out snippets of clutter accumulate. Your version control tool maintains history. Go ahead and delete the junk, you can always get it back.
2. One Giant Commit
Some people get it right by working in a branch of some sort. But even so, they don’t commit changes until their work is 100% complete. If your tool supports branching, you should commit to your branch frequently. This gives you a great backup mechanism and lets you easily back out unwanted changes should you discover a problem with your approach. Too often, people work on huge tasks for days and weeks at a time, performing a single monolithic commit at the end of their task. This introduces great risk should your hard drive go bad near the end of your task.
3. Using Physical Copies as a Backup Mechanism
How many times have you seen this? Before making a change, programmers copy their source code — manually — to some “backup” location on their hard drive. This gives them a sense of security because in their minds, they can easily revert to the original version of the source files. Uh, this is what your version control tool does for you.
4. Human Edited History Logs
This “worst practice” is frequently mandated by coding standards committees. Comment blocks like this:
// Audit history // 10/15/2006 - J Smith - Made the account number longer // 10/22/2006 - W Bannerman - Fixed NullPointerException // 01/06/2007 - JJ - performance enhancements
These comments are generally wrong because one or more programmers forget to update them. Manual human practices are highly prone to failure. These comments are completely redundant with the history provided via the version control tool. It’s better to simply mandate revision comments whenever committing changes.
Using Physical Copies as a Backup Mechanism
I sometimes copy my source tree before doing a push because when I work with someone on the same branch, I often have to merge my working copy with the trunk head.
Sometimes merging is not a very straight forward task and having a copy of “something that I’ve tested and know to be working” near helps a bit. Git firstly commits my original “something that I’ve tested and know to be working” work and then creates a new commit with the merging details; other SCM tools do not provide such a feature (svn, cvs…). I know I can retrieve it through git, but it’s faster and more straight forward this way.
I dont quite agree with you on no 4. Human Edited History Logs.
I personally believe that this is what constitutes a manual page, detailing all changes that have happened to this file. However trivial it maybe. Tomorrow , if you change ur version control, where do you think your history will be stored. You will end up with a fresh slate of modified files. Without these audit logs, you wont be able to assign responsibility(or blame)
-Sashidhar
Yikes. If you switch to a new tool, migrate the history to the new tool as well. If you can’t do that, then keep the old tool around for the history up to the point of the conversion.
#1 usually starts when you delete code written by ‘The Expert’ who’s been with the company 10 years or so and you get yelled at for doing it. At one such company, I saw massive amounts of commented out code that had DO NOT DELETE!!! headers on each section.
#2 happens when branching isn’t well supported in the VCS or when departmental policies don’t set check-in/check-out and branching procedures
#2 and #3 also often start when the VCS is hard to use or is unreliable. I’ve also seen #3 used as a political tools as well.
#4 is a bit of “mainframe mentality” that’s still around. I could see it if you were using a VCS that didn’t allow developers to comment on their changes within the system or generate reports but, otherwise, use the system and create change reports as necessary.