5

Recently, I forgot to merge changes from trunk to our maintenance branch. This caused us to rebuild - twice - and put QA on hold for two days while we fixed the mess.

Normally, when committing to both branches, I commit a single changeset to trunk, and immediately merge it over to the maintenance branch.
However, this time there were 12 changesets spanning many code review changes, and I failed to merge all of the changes over. I had only merged one change over, which completely threw me off - I thought I remembered it was a rollup commit of all of the other changesets, but it wasn't.

After some development discussion, we decided that the best approach would be to make 1-to-1 trunk and maintenance branch commits, so you could visually verify that all of the code was there.

Is there a way to enforce changeset commits for a given fix-for version?
We use JIRA, Fisheye, and Crucible, and our Fisheye workflow won't let you resolve an issue unless the code reviews are complete. I'd like something similar that enforced parallel checkins on trunk and maintenance branches, based on the fix-for version specified in the issue.

Or is there a better solution to this whole mess besides "don't do that"?

Improve this question
0

3 Answers 3

Reset to default
4

Obviously this only works if you use git, but here's how I'd approach it...

Each feature request, and each bug, get their own branch locally. The developer then does all the changes needed. When they're done, rebase the branch and merge/split the commits into logical work units. For small features and for bugfixes, this shouldn't be hard to keep them at a single commit. For larger features, you may want to have multiple commits, eg: "Add interface for foo". "Add implementation of foo". "Have Whizbang use the new foo feature". The point is to keep all logically connected lines of code in one commit. At that point, the work unit has one (or a set) of commits. Your bug tracker should let you link commits to tickets. The bugfix ticket would link to the bugfix commit and it should be easy to see that the commit was merged onto the proper release branch.

Improve this answer
2
  • Right now we use Subversion, which makes feature branches a pain, but Git is starting to pique the interest of more and more people around the office. I'm actually doing something like this on my local dev machine. I think we may eventually move to a model like this.
    – mskfisher
    Jun 3, 2011 at 4:48
  • 1
    Use git-svn locally; show other people that VCS doesn't have to be painful; convert. That's the best way
    – Daenyth
    Jun 3, 2011 at 13:09
1

At my job we have home-built software that helps us start/end projects. When you land the project, it creates a tree, applies your changes, then merges any changes in the trunk. (You resolve conflicts there.) When you end it commits those (and deletes your project).

When you start a project you specify whether it is a hotfix or not. If it is a hotfix, then when you land it it builds patches both to the trunk and the maintenance branch.

Of course now you have to remember to make the project a hotfix. But it makes it easy to make sure that a whole lot of related changes all will get committed together where they need to be.

Improve this answer
1

What you did is likely a result of a process defect that requires you to remember to do it, (hence you do it immediately), with no tracking that it did really get done.

Question : Can you easily produce a report that confirms all merges have been complete. If so, can the failure by a single individual of a single action cause the report to be incorrect (i.e. does you process have a single point failure mode)?

You actually have 2 changes required. One is delivery to the main branch and one is delivery into the maintenance branch. Use Jira to track these as two related deliveries.

This has advantages, such as you can defer a merge into the maintenance it desired, and still see what has been deferred, but does have an overhead. It also may make your reporting system to management report more defects that you really have, depending how you record and report these.

Improve this answer
1
  • I think you've got the right idea, but since we can mark multiple fix-for versions in each Jira issue, I think it should be possible to leave them both as a single issue and make the reporting track the commits on both branches. So yes, I need to investigate whether Jira can track Fisheye commits on multiple branches - and then confirm that similar changesets were committed to both.
    – mskfisher
    Jun 3, 2011 at 4:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.