At my current place they use SVN like they would use stones and sticks.

Most commit messages are only the code of the Jira issue and maybe its title, but almost never what they actually did or why. Frequently, they will have half a dozen commits with the same message -sometimes even unrelated commits because they got a bit too lazy-. Most Jira tasks don't have a description. If it's a new development, the documentation is generally elsewhere and the Jira task has no description at all. If it's a bug, it may have some screenshot attached, and it sometimes has an explanation but generally the explanation is given verbally to the developer.

A handful of developers heard The Architect say once that it's preferable to submit one commit for each changed file than to put two unrelated changes in the same commit, and so they do. They change 12 different files for a certain feature and they will make 12 separate commits, one file each. Not always one after the other but sometimes dispersed through the day. One or two developers obsessively commit each single change they do. Meaning they write a couple of lines of code, commit it, and then try it, see it wasn't correct -there was a typo, it wasn't the correct field they needed, whatever-, edit again, commit again, etc.

They have a certain backup process which stores a handful of XML log files from some processes; they store them by committing them to the SVN repo. A commit every hour, in the development branch.

They have a flow with two branches, trunk and development, and a 6 month cycle for releases... It sort of works this way:

Start (theoretical): People develop on development. Two -or two and a half- months before release, they make "the switch". Everybody commits whatever they are doing at the moment and stops for a day. They merge development into trunk. and then they all start working on trunk for the rest of the cycle until release.

In that final period, trunk is mostly "open" -more on this later- and people just commit to it and that's it. development is abandoned and deleted. A new development branch is taken from trunk but is not generally used during this period.

When release time comes, trunk is tagged with the version. Everybody switches back to the new development and development is done there. But this is not what happens because there's another period of maybe one or two months, where trunk -the released version- has a number of a. bugs, b. stuff that was unfinished, c. smaller things which "well, we could do it on trunk because it's just a small thing". So, what happens is they go on working on trunk for that month or two, and only gradually people start working on development.

Also, they don't really tag trunk at release time because it's not "done" yet. When the bug hunting season is over -or when they are just tired of it- then they tag and freeze trunk, with the version, move it into storage. Nothing in this is really planned. They just decide one day and then tell people, who just rush whatever they were doing on trunk and commit it, or abandon it and move to development.

During both pre-release and post-release periods, merges are done about once or twice a week from trunk to development. If you use SVN you'll know that these merges are seen as a single commit in the receiving branch. You can see the full history if you query the merge info, but it's not shown directly in the main "svn log".

All this means they have:

- about 40% automated commits from some backup process.

- Most changes happening in the other branch, so you need to go through mergeinfo several times.

- Main development branches deleted and created new every so often.

- Most people not explaining what they did in commit messages.

- About half of the bugs in Jira not describing the problem and almost all of the tasks not explaining the work to be done.

So... do we ever truly use the revision history?

Yes.

A few people -particularly Karen- use it to drop the blame on whoever they want. They get a bug, they open the svn log for something related, see a name they don't like much and say "Ok, just assign this to X, because they did something on that file 4 months ago".

I am using it, sometimes -with some effort and some success- to try to understand just where do some heavily copy-pasted snippets come from, so that I can wipe them out for good. Also, sometimes I use it just to write in my diary and laugh a bit about it so I don't cry so much when I get up in the morning. This is probably the most valuable thing we get out of it, because it keeps me... well, insane, but at least not murderly insane.