Here's a real world example of Version Control saving thousands of dollars of developer time. From three days ago:
Text is rendering blurry in the thing I'm building. It used to look nice and crisp, but now its as though it's all nudged half a pixel off the grid. It looks terrible. And I don't remember having touched the text rendering stuff or the vector code recently. wtf?
So I pull up the change log for the project and it gives me a giant list of everything that has ever been done on it back to version one where it was nothing but "test.html" moving a yellow box around the screen in time to an audio track. I grab a version from a few weeks back, 50 checkins ago, and click "update to this version". Reload the project in a new tab and sure enough: beautiful crisp text. Tab over to the current version: blurry blurriness.
So it's on. Jump forward to yesterday: still bad. 2 weeks ago: good. 1 week ago: bad, and so on. Until I'm looking at one checkin that definitely contains change that broke this. As luck would have it, it was a big one, so I get to try individually updating each file in turn. And since the culprit is nowhere near touching either text rendering or vector stuff, I get to go line by line on it until in disbelief I find the single "if" statement that's been flipped to a configuration that allows opacity animations to occasionally get left at 0.9997 instead of locking them at 1.0.
And we're fixed. In ten minutes.
Now I can honestly say that I don't think I would have found the cause of this bug without version control. All the places I would have thought to look were innocent, and the most innocuous thing in the world turned out to be the culprit. With nothing but tarballs and hand-renamed folders I would have been completely screwed. Not just more time to fix this, but several orders of magnitude more time. And most likely we would have simply resigned ourselves to ship with blurry text and kept an issue in the tracker about it for years.
Now, in case you missed it, this happened to me three days ago. It's not some isolated instance I heard about once. Version Control saves you like this on a daily basis.
If you see a software company that's currently in business and shipping software, I'd say you can use that as empirical evidence of the value of version control.
Also, if you are using git, `git bisect` will do a great job at automating this kind of history search. It'll also do a nice binary search quickly narrowing down the culprit.
Additionally, you said "As luck would have it, it was a big one," - this is what I personally use `git add -p` and `git rebase -i` for before pushing to the public repo: I try to keep the commits as small and self-contained as possible such that finding the faulty commit gets much simpler, because there will be no "big one".
Keeping commits small is crucial. I've been bitten by the "big commit" enough times to force myself to keep commit diffs to a few lines across a few files.
I even go as far as to put "formatting" changes into one commit, and actual code into a separate commit. Formatting changes tend to be things like "unindent this large block of code", or "strip extraneous whitespace".
They can be larger than usual commits, but they allow me to separate functional changes from non-functional changes. And yes, I've seen a non-functional change break working code before.
Sure you can. Just render the glyphs into a framebuffer and check the ratio of opaque pixels to semi-transparent ones. The more transparency the blurrier. But I agree with the poster below that it is usually to much trouble and only worth it if your software is deep down in the stack. For example, if you are writing a text rendering system it would make sense for such tests but not otherwise.
Text is rendering blurry in the thing I'm building. It used to look nice and crisp, but now its as though it's all nudged half a pixel off the grid. It looks terrible. And I don't remember having touched the text rendering stuff or the vector code recently. wtf?
So I pull up the change log for the project and it gives me a giant list of everything that has ever been done on it back to version one where it was nothing but "test.html" moving a yellow box around the screen in time to an audio track. I grab a version from a few weeks back, 50 checkins ago, and click "update to this version". Reload the project in a new tab and sure enough: beautiful crisp text. Tab over to the current version: blurry blurriness.
So it's on. Jump forward to yesterday: still bad. 2 weeks ago: good. 1 week ago: bad, and so on. Until I'm looking at one checkin that definitely contains change that broke this. As luck would have it, it was a big one, so I get to try individually updating each file in turn. And since the culprit is nowhere near touching either text rendering or vector stuff, I get to go line by line on it until in disbelief I find the single "if" statement that's been flipped to a configuration that allows opacity animations to occasionally get left at 0.9997 instead of locking them at 1.0.
And we're fixed. In ten minutes.
Now I can honestly say that I don't think I would have found the cause of this bug without version control. All the places I would have thought to look were innocent, and the most innocuous thing in the world turned out to be the culprit. With nothing but tarballs and hand-renamed folders I would have been completely screwed. Not just more time to fix this, but several orders of magnitude more time. And most likely we would have simply resigned ourselves to ship with blurry text and kept an issue in the tracker about it for years.
Now, in case you missed it, this happened to me three days ago. It's not some isolated instance I heard about once. Version Control saves you like this on a daily basis.
If you see a software company that's currently in business and shipping software, I'd say you can use that as empirical evidence of the value of version control.