Remove Empty Branch Trigger
Remove Empty Branch Trigger: This trigger removes the branch and the zero element that is left when a user checks out an element on a branch then cancels the checkout. Normally this causes a branch with only a zero element which is identical to the version from which it was branched. Essentially this empty branch is useless. This trigger prevents that.
Not only is this empty branch useless but:
- It clutters the version tree
- Causes Clearcase to maintain more meta data, slowing down operations
- Can cause additional work for UCM when you rebase
I'm experiencing that last bullet item right now. At one time I was attempting to do a delivery for somebody from another stream, first rebasing my stream. The delivery was unsuccessful and it was decided that this other engineer would work on it and deliver himself. So I canceled the delivery. One would think then that my view was relatively clean.
However now I want to deliver something else and I see this old rebase activity hanging around. In looking into the change set I notice a bunch of items from that older attempt at delivering. Why were these still hanging around? I had canceled that delivery right?
Well I believe the problem comes from having empty branches. Take for example the following:
It shows a rebase from osaka/5 -> defaria_osaka/1. Yet these two version compare to be the same! How did this happen? Well think about it. Prior to the rebase I had an empty branch (i.e. I had defaria_osaka/0 left over from the canceled delivery which merely did an unco). This means that osaka/4 and defaria_osaka/0 were identical. Then osaka/5 came into existance. Now 4 != 5 and when I rebase Clearcase has to propogate osaka/5 creating defaria_osaka/1. Now I have two identical versions and associate meta data and all for naught! Additionally I have a baseline lable on defaria_osaka/1 which give the air of importance to this unimportant version.
Had we had a remove empty branch trigger, when the delivery canceled, the unco would have left defaria_osaka/0 and the remove empty branch trigger would have removed the empty branch. Then my view would have been pointing to osaka/4 (and would have moved to osaka/5 if I were using .../osaka/LATEST and a dynamic view or updated to osaka/5 during the normal course of updating the view). Indeed, allowing empty branches to persist can cause developers to unknowingly get "stuck in time".