Using them all the time: - Looking at root causes of undocumented weird hacks and technical decisions - Finding culprit, the one that causes a bug, in order t

Using them all the time: - Looking at root causes of undocumented weird hacks and technical decisions - Finding culprit, the one that causes a bug, in order to remind them to do better. - Finding out someone underappreciated contributor - Reverting changes. - Cherry-picking changes. A REMINDER: Revision history is great, but so is flexibility and velocity. You can always cut off history and use another tree (e.g. when moving from SVN to git), make a documentation about it, keep the SVN history as an archive and use git. If a decision will boost velocity, flexibility, and sacrifice less valuable thing, you should do it, but make sure you will have a fallback. In the end, flexibility is what you will need at every level (code, product, company) because the world around you (and requirements) always changes and you'll need flexiblity to be adaptive.