Disclaimer

The content of this blog is my personal opinion only. Although I am an employee - currently of Imagination Technologies's MIPS group, in the past of other companies such as Intellectual Ventures, Intel, AMD, Motorola, and Gould - I reveal this only so that the reader may account for any possible bias I may have towards my employer's products. The statements I make here in no way represent my employer's position, nor am I authorized to speak on behalf of my employer. In fact, this posting may not even represent my personal opinion, since occasionally I play devil's advocate.

See http://docs.google.com/View?id=dcxddbtr_23cg5thdfj for photo credits.

Thursday, May 24, 2012

Rewriting history in version control systems

Some people like rewriting history in version control systems. These people do not want "history" - they do not want an accurate record of events. They want a "narrative", an arc of development. With some of the ugliness and irregularity of what actually happened removed. -- Recently overheard: "Oh, we can't go back to the version used for that test, because somebody rewrote history." -- My take, as explained earlier: Record the history. The real, raw, history. (Heck, I am occasionally willing to check in broken code - on a branch., NOT into the main line. NOT released to others. E.g. sometimes it is worth recording, in the project history, all of the standing upon your head that you had to do to work around compiler bugs.) But clean up the history, the logs, the narrative, when releasing. Merging back into parent branch. Etc. And teach people how to look at the cleaned up history, the narrative. And only have to look at all the details if absolutely necessary. -- A simple example of a narrative versus history: It sometimes happen that two features are implemented in an interleaved manner: Feature A - first step Feature B - first step Feature A - second step Feature B - second step Now, while it would be nice if somebody created separate branches for feature A and feature B, we all know it doesn't always happen. That is why we may be rewritging the history, cleaning up the narrative. It may look better as Feature A - first step Feature A - second step Feature B - second step Feature B - first step i.e. do both steps of Feature A, then both steps of Feature B. Or even, retroactively create separate branches. This can actually be accomplished by creating new branches, selectively patched and merged. But, it may not be worth the work to do this. But it may be worth the work to record the narrative showing it. So long as the actual history is also stored. Heck, perhaps tools could make it easier to reconstruct the narrativem, as it woulda/coulda/shoulda happened. Albeit with a warning "This is not an actual historical reconstruction, so it may not actually work".