Is assigning a ticket number to a checkin with version control worth the effort for developers?

Question

The practice I'm discussing is: Your project/product has a ticketing system for bugs, features, etc. There is also have source control. However, it always seems that there is a reason to try to tie these two together. Some places don't want a checkin without a ticket number. Some development shops are looser about the requirement that there exist a ticket for every checkin, and will let in a minor checkin or two slide without a ticket number attached.

Question: What makes this practice so useful?

I've seen this practice in various places in my career. This is especially evident in products such as Microsoft's Team Foundation Server. I've seen in at IBM with CMVC, their home grown source code management system. I've seen in with Mingle and SVN, or SVN and Redmine, where you can associate tickets to checkins by simply putting the ticket number in the commit message. In all these places, I really haven't found it to be useful in my own work, so I realize that it should be useful somewhere down the line.

Answer 1

If you have a ticket number on a checkin you can refer back to the bug report to see why the edit was made. This is often as important, if not more important, that the actual edit itself.

Answer 2

We do it, but not religiously. We use Trac internally, and once you have that link up working, you can look at a ticket and easily review the changesets which were carried out for it. FOr complex tickets this is very useful, particular if any sort of code review is required.

WHile the practice does let you see more of the background into why a change was committed, in practice we've found we don't use that so much. But it's nice to have, and all you need to do is mention the ticket number in the commit message.

Answer 3

There's plenty of value - whether you're offering commercial support, or running an open source project. If you're supporting your product, and someone calls in to report a bug, you can check to see if the bug's been reported, and if it has, if there is a fix in place, tested, etc. On an open source project, where people may be running versions of software pulled direct from source control, if there's a bug fix, or a feature they're wanting, they can check the issue tracker and find out if it's fixed in a more recent version.

Answer 4

It may be useful if you can tie both together, for example, we have a script that takes the commit message and adds to the bugtracking ticket if you provide the issue number. Its usefull for managers and control freaks, so they follow the issue status in one place by reading the messages instead of disturbing developers directly.

Answer 5

It comes in very handy in lieu of good requirements specification or requirements traceability. Its useful when doing archaeology to explain the current state of the system.

Answer 6

Tells you who made the fix :o)

Answer 7

It tells you :

• something was actually done
• who's responsible
• what was changed
• the change was related to the defect only
• any regressions that you might discover later on
• verifies your timesheets, if any ;)

Answer 8

I've found that the most useful aspect of doing this is when reviewing commits by other devs as they come in. The repository is set up to send out an e-mail for each commit that includes the commit text and a diff. Reviewing this can be essential to keep up with what is going on in mid-sized project.

Often the check-in text will explain what has been changed but not why, the "ticket" can then fill you in if need be.

Sometimes the issue tracker contains lengthy discussions on exactly how to deal with difficult problems and reading it can give you an understanding of why some decisions were made. That's quite valuable.

Of course the usefulness of this will vary from project to project.