DCVS and Bug Database

Question

I am considering implementing the following policy and would like to run it by the community before implementing it:

All mercurial commits must have a bug id corresponding to our bug reporting database.

All commits immediately preceding a push for a new feature must have a bug id (it's a new feature but the id is still a "bug id" in the database)

This will do several things. First, it will ensure that an entry is always put into the bug database for all code changes. Second, it will provide a diff of each change made for each bug fix. This would also simplify commenting in the mercurial commits and put most details about the commit into the bug report.

Do you know of any reasons why this would be a bad idea? Also, do you think I should make some additions to this policy?

Answer 1

You definitely do not want to enforce this policy on all commits. One advantage of DVCS is that developers can commit and promote changes to private branches at any time. It's a reasonable policy for commits to production code in the central repository.

Answer 2

We do this where I work (in theory).

It's genuinely really helpful when people do it right, as you can go into the cases in our particular bug-tracker-of-choice and see that you're getting the right changesets for a particular release based on the case IDs of the features you're adding. Your point about keeping the comments on the case is another plus, as in my experience no-one will read your commit messages.

However, it's a pain when people either put the wrong case ID on or just plain don't bother, so I'd say if you're going to do it make sure you have a staging repo where you're able to change the case ID before you push it into your trunk, and add a policy to the remote end to reject changesets without a case ID on them.

Answer 3

1. Documenting all changes in form of tickets is, in common, good style
2. Direct links ticket-changesets is good

But

1. Some changeset may be indirectly related to issue (1-st CS - changes for ticket, 2-nd+ - fixes for CS 1)
2. Flat history with only commit-messages doesn't provide nice interface for filtering from VCS-side
3. Branch-per-feature workflow hide side-effects of 1 and 2 and make marking all changesets obsolete even from issue-tracker side - referenced maybe only first and last commit

Answer 4

People do not look in bug databases to see code diffs for bugs. They look in version control. Therefore, it makes sense to require a bug id for the last commit that fixes a bug, so you can make a note in the bug tracker and identify what build bug fixes are in, but every single commit is overkill.

If people are committing features you don't want, you have a whole other problem, and probably need some sort of gatekeeper workflow. I'd highly recommend you look into more integrated solutions like kiln or bitbucket.

Answer 5

The more obstacles you put in the way of me committing, the less often I'll commit. That really defeats the point of a DVCS.

You're really trying to solve a symptom with this approach rather than trying to fix the root cause. You have a team of developers who:

• Don't understand the value of the bug tracker;
• Don't seem to communicate very well, and repeat work that other developers have already done;
• Veer off-task and write code that hasn't been discussed and hasn't been authorised.

You could enforce this policy. However, if the developers are already dysfunctional, what is this policy really going to achieve? Is it suddenly going to give you a focused, communicative team who maintain an excellent set of bug reports?

No. It will give you an awful lot of bug fixes checked in against the wrong bug report.

You need to address the issues in your team by managing them. Show them how they are stepping on each other's toes. Hold daily standup meetings so that Bob can tell the team that he's fixing bug X so that Dave won't start work on the same thing. Explain the value of the bug tracker. If your developers come to see that what you're trying to achieve is a good thing they'll do it automatically.