Everyone who has worked in Software Development for long enough must have heard somebody say that source control ate their files – it’s up there with “Works on my machine” and other such silliness.
Invariably source control didn’t eat their files at all – the problem boiled down to a (sadly) not too uncommon condition of “Fear of Source Control“.
Here are some of the symptoms of such a fear.
Unwillingness to do an update
I worked on a project years back with a tight deadline, not a huge amount going on in the way of process and about 6 developers all coding like hell.
Invariably, every other update broke your local build as someone had changed an interface or forgotten to check in a file (we had no daily build either), so yes, updating was a pain.
For two of the less experienced team members their solution to this problem was to hold off updating as long as possible (they’d happily go two weeks without doing an update).
When I queried their approach their answer was that doing an update “broke things” so was best avoided.
This symptom of course goes hand in hand with…
Unwillingness to do a commit
As anyone who has worked with source control systems long enough knows, they won’t let you commit a file if there are outstanding changes to be merged in.
So, leaving long gaps between updates almost always leads to massive problems when you finally commit your changes.
Long update intervals lead to long commit intervals.
My usual solution to this is to do an update every morning before I start any development work for that day.
Of course, I now work on much saner projects where things don’t break so often (or when they are likely to break things then someone has already warned you in advance).
That way I get the small amount of pain out of the way without huge disruption to whatever I am working on.
I then commit my work once it’s complete and passes its tests.
I also try to pay attention to what my colleagues are doing on the project too so I can avoid nasty surprises.
Deleting other people’s code
I have seen this happen, usually when someone gets a merge conflict.
Merge conflicts are what happens when two people work on the same code at the same time and the changes from one person’s work are merged into the other’s work.
Sometimes this happens smoothly and everybody is happy and sometimes not so smoothly and one person is very unhappy.
In the face of a merge conflict the correct approach is to fix the code by hand, which often involves talking to the other person who worked on the file to ensure that both their changes and your changes are preserved.
The incorrect approach (and yes, I’ve seen it done) is to remove the offending lines (someone else’s code), keep yours and commit away. This is of course a “bad thing”.
Merge conflicts are of course best avoided, even experienced developers strongly dislike them.
The way to do this is through communication with your fellow team members and knowing who is working on what area of the code (Scrum-like daily meetings are great for keeping up with who is doing what).
Often, said conflicts can be avoided by a bit of advance planning (you do your bit, test and commit, then they update and pick up your changes before they do their bit etc).
Commenting out unused code
If you’re lucky it will be accompanied by a vague comment along the lines of “I don’t think this is used any more” .
This stems from the fear of not knowing how to use source control to retrieve old versions of a file.
The correct thing to do of course is to remove it, then commit that change and mention said removal in the commit log.
If the code is being replaced then a comment along the lines of “Replaced foobar1 with foobar2 – foobar1 code lives in version 4.1.2 in CVS” would be most appreciated by future developers (which could of course be you).
Committing backup versions of files
I’ve just finished working on a project where a binary file that was kept in CVS had no less than 7 alternate versions (none of which were used) checked in alongside it.
I spent ages working out what each one did, seeing it did nothing, then removing it from CVS.
Again it stems from confusion and fear of using source control to get access to older verions of a file.
The solution to all of these problem is of course to “lose that fear” and learn to love your source control tool.
One good way to start doing this is to stop using a GUI to manage your source control tool and learn the command line instead (assuming your tool has that option).
That will remove a lot of the mystery of what is going on.
Learn the mechanics of your source control tool by reading the manual.
Eric Sink has an excellent series of posts on source control that highlight some of the many benefits of using it.
The final thing to realise is that correct use of source control will save your bacon.
The initial learning investment will be repaid time and time again.
And that, is worth its weight in gold.