Ask HN: Do you ever truly use your revision history?
At my current place they use SVN like they would use stones and sticks.<p>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&#x27;t have a description. If it&#x27;s a new development, the documentation is generally elsewhere and the Jira task has no description <i>at all</i>. If it&#x27;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.<p>A handful of developers heard The Architect say once that it&#x27;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 <i>then</i> try it, see it wasn&#x27;t correct -there was a typo, it wasn&#x27;t the correct field they needed, whatever-, edit again, commit again, etc.<p>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 <i>development</i> branch.<p>They have a flow with two branches, <i>trunk</i> and <i>development</i>, and a 6 month cycle for releases... It sort of works this way:<p>Start (theoretical): People develop on <i>development</i>. Two -or two and a half- months before release, they make &quot;the switch&quot;. Everybody commits whatever they are doing at the moment and stops for a day. They merge <i>development</i> into <i>trunk</i>. and then they all start working on <i>trunk</i> for the rest of the cycle until release.<p>In that final period, <i>trunk</i> is mostly &quot;open&quot; -more on this later- and people just commit to it and that&#x27;s it. <i>development</i> is abandoned and deleted. A new <i>development</i> branch is taken from <i>trunk</i> but is not generally used during this period.<p>When release time comes, <i>trunk</i> is tagged with the version. Everybody switches back to the new <i>development</i> and development is done there. But this is not what happens because there&#x27;s another period of maybe one or two months, where <i>trunk</i> -the released version- has a number of a. bugs, b. stuff that was unfinished, c. smaller things which &quot;well, we could do it on <i>trunk</i> because it&#x27;s just a small thing&quot;. So, what happens is they go on working on <i>trunk</i> for that month or two, and only gradually people start working on <i>development</i>.<p>Also, they don&#x27;t really tag <i>trunk</i> at release time because it&#x27;s not &quot;done&quot; yet. When the bug hunting season is over -or when they are just tired of it- then they tag and freeze <i>trunk</i>, 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 <i>trunk</i> and commit it, or abandon it and move to <i>development</i>.<p>During both pre-release and post-release periods, merges are done about once or twice a week from <i>trunk</i> to <i>development</i>. If you use SVN you&#x27;ll know that these merges are seen as a single commit in the receiving branch. You <i>can</i> see the full history if you query the merge info, but it&#x27;s not shown directly in the main &quot;svn log&quot;.<p>All this means they have:<p>- about 40% automated commits from some backup process.<p>- Most changes happening <i>in the other branch</i>, so you need to go through <i>mergeinfo</i> several times.<p>- Main <i>development</i> branches deleted and created new every so often.<p>- Most people <i>not</i> explaining what they did in commit messages.<p>- About half of the bugs in Jira not describing the problem and almost all of the tasks not explaining the work to be done.<p>So... do we ever truly use the revision history?<p>Yes.<p>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&#x27;t like much and say &quot;Ok, just assign this to X, because they did something on that file 4 months ago&quot;.<p>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&#x27;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 <i>murderly</i> insane.