Question

I am struggling with a perceived conflict between tracking all my changes so I can figure out where I broke the code yesterday, and having a controlled (high overhead) code review process that keeps things sane.

I work in a very traditional ClearCase shop. All checkins require code review and I lack the authority to create private branches. In order to satisfy a primal urge for version controlling all my daily work I use mercurial from with in the clearcase view this only sort of works

I seek the collective wisdom as to what is the best way to keep track of my daily changes while playing as nicely as possible with the clear case folks.

Answer 1

I am not familiar with ClearCase, hence the scope of my answer will only be mercurial.

I consider your following problem: I track changes locally to be able to save my steps even if steps are incomplete/broken, and then I submit the whole picture for review, but it often turns out being commits that are too big and not easily reviewable. Am I correct?

To solve this particular problem, I use Mercurial Queues. These queues allow you to basically edit your local unpushed commits, to reorder and to fold several patches into a single one/or split one commit into small readable chunks. Before reading more about it, here is my suggestion on how you would use them:

• You do your usual work. Do small easy commits, as you wish, according to your own personal standards because the commits will not be seen by your coworkers. Break the build if you have to, do whatever you want to do.
• Once you get the whole big picture, the 4780-lines long patch, pause.
• Import your local commits in your mercurial queue.
• Review your successive commits locally, and ask yourself “how can I make this readable?”. For example, you will identify groups of commits on the same feature. Or several attempts at fixing the same problem.
• Once you have identified meaningful commit groups, reorder your patches (reorder your commits: that’s what Mercurial Queues allow you to do). After this, fold similar patches together. For example, if you have successive attempts n, n+1, and n+2, where n+1 partially undoes n, and n+1 is a typo oneliner… well just merge the three commits into one single meaningful commit “this commit completely fixes issue #1212313 doing this and that”.
• After reorganizing your pile/queue of commits, you will end up having a serie of small meaningful patches. Because they are small, they are easily readable. Just submit the serie of meaningful patches to your coworkers: if each patch is clean, small, and addresses a single issue, review time will be very small.