views:

57

answers:

1

I want to throw this scenario out there and see what the most objective, vanilla-Mercurial way to fix this would be.

Suppose I have the following branches in my centralized Mercurial repository for my centralized, non-distributed web-app:

repository
    default
    feature1
    feature2
    bugs

Suppose ten developers have committed fixes to the 'bugs' branch and pushed. Now let's say it comes time to release. So, I do some final tests, and suddenly, I notice a problem with a bug fix--and this problem is going to take a few additional hours to fix. So, now I have super critical bug fixes that have to be released, but the 'bugs' branch is locked up, and I can't merge into the 'default' branch and release because the half-fixed bug will also be released, and I can't let that happen.

So what do I do?

Should I revert the change in the bugs branch, merge bugs into default, and release? What if there are ten commits associated with this particular problem-bug-fix--find and revert all those? That sounds hairy, but let's say I do that. What about when the developer who has to fix the problem-bug-fix pulls and updates his repository? His changes will all be reverted. He COULD un-revert the revert…is that the way to go?

Another option would be to do some kind of cherry picking and merge just the changes I want to release from the 'bugs' branch, minus the problem-bug-fix commits, into the 'default' branch. But this sounds even hairier than the previously-proposed solution.

What do you all do?

+1  A: 

I would create a new branch (to make the release):

  • starting from the current "locked" branch bug
  • with a revert of the problematic bug-fix

And I would leave the "bug" branch as it is. No cherry picking.

VonC
So once we've created the new branch and reverted the problematic bug fix, are you suggesting we merge THAT new branch into default and release from default? Or are you suggesting we release right from that new branch?
Chad Johnson
@Chad: you can release directly from that new branch. The trick with release management is: "The branch from which the release has been produced... is not that important. The **tag** is." If the release has issues, you need to be able to reference the right sources from the right tag. The fact that this tag has been set on branch b1 or b2 or b-blah is not that relevant.
VonC
Hmm, very good to know. Thanks Von.
Chad Johnson