tracking daily changes, as a peon, in a clearcase shop

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

Answer 1

I'm with tanascius and Stephen. Just because you use mercurial to track personal changes doesn't mean you cant submit earlier to ClearCase for review. The problem isn't mercurial or ClearCase it's submitting 4780 lines of code for someone to review.

I also work in a shop with strict review policies and Perforce. I use git to track local small changes but I still send off for review before the change gets to big for my co-workers to comprehend it.

Commit early and commit small.

Answer 2

Did you talk with your co-workers about your problem? They should face the same problem and maybe have some good ideas.
I would try to ask your boss for permission to create branches - or at least to get one private branch. But working with this branch does not change your current problem. When you dump 4780 lines for a code review no one cares where they come from.
You should really try to check in early and often. If you need to experiment in a private branch - fine. But as soon as you get a result you should commit it and get a code review.
Using mercurial does not sound like the "official way" - does your boss know about it? Is it regularly backuped? That's why I would go for the private branch. Make your workflow offical before you get into trouble.

Answer 3

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.

Answer 4

Commit early and often. Your colleagues will appreciate the smaller code reviews and the changes will be easier to manage and merge. Focus on biting off small pieces of work and then committing these.

What problem do you face with keeping track with your daily changes? Doing a clearcase diff will tell you what you have changed.

Answer 5

All checkins require code review and I lack the authority to create private branches.

We are using ClearCase too and have development branch (not a branch per developer!, but a branch for a "development effort" involving one to a few developers) in order to checking early.
The rule though: it must compile and pass basic unit testing. If the CI - Continuous Integration tool - "gets red", everyone in the team of that development effort stops. And help to resolve the bug.
That way, we commit early and fix early.

Then a consolidation branch helps to report code that have pass stricter control (code review or some advanced testing).

It is all about having a merge workflow.

For very intermediate commits, I use Git right within my ClearCase View (a simple "git init" inside a ClearCase view, and you have your very own Git workspace ready!).
Any number of private branches can live in this workspace, helping with private experimentations.
A "git bundle" helps me to backup the current state of that Git workspace into a file save outside my workstation.

---

how do you handle moving from one clear case view to another?

That is the drawback of a merge workflow: with ClearCase, you have to set up as many view as you have Streams (with UCM) or branch (non-UCM). We use dynamic views for the merges and their resolutions, and then snapshot views for development.
Since we have different views for different streams, we can easily compare two different development effort with a simple WinMerge.