SVN integration with bug tracking / ticketing software

Question

I was wondering if there is any software that integrates the ticketing system (or error tracking) with SVN, but in a certain way. I want to prohibit any code changes that do not have a ticket (or an error identifier).

For instance:

• Each developer has read-only access to SVN - he can update sources, but cannot commit.
• Each commit must contain a bug / ticket identifier
• Even for optimization tasks, the developer must create a ticket for himself, and then implement some things.

I know that there are some tools like Mylyn that help with the ticketing system / SVN, but the developer can always capture the sources.

I don’t have an environment for the ticketing system (I can use Trac, as well as BugZilla or any other), but SVN should use it as a code repository.

Do you have any idea how to integrate these services in this way?

Answer 1

For such a policy, you need to write a Hook Script that checks the ticket identifier in the journal message and, of course, checks whether the ticket identifier belongs to the corresponding project. You can also use things like Redmine as a ticket system.

Answer 2

I recently used TFS. This has the ability to set up a similar workflow - you need to create "work items" to which you can attach errors with which you can make changes. This cannot be done without first creating an error, without first creating a work item.

This went crazy and I changed the settings because my workflow was as follows:

• We are pleased to edit the code to fix the error.
• Find another, unrelated error.
• The source code changes the first error.
• Stop the flow and start the work item editor.
• Set out the VS2010 frontend and create a new work item.
• Look at the awful VS2010 error debugger and create a new error.
• Return to the code.
• Determine where the second error was.
• Fix the second error.
• Return to work on the original error.

Actually, my workflow was more like this:

• We are pleased to edit the code to fix the error.
• Find another, unrelated error.
• Think: "Fixing this line of code will take me a good hour to mess around with stupid error trackers."
• Keep working on the original bug.

The overall effect is that the errors that I could fix in the blink of an eye remained in the system, because I was not going to spend my time on absurdly bureaucratic error reporting systems. What is more important for you - happy, productive developers or impressive reports extracted from SVN?

Answer 3

If you really want to, you can take a look at gurtle, a turtle plugin that allows users to list bugz. Following this pattern, you can offer a quick and easy way to create a case / issue if it is not.

In addition, I must say that I believe that your goal is wrong and counterproductive. Some well-thought-out processes / policies sometimes sound good, but in practice they become a nightmare and waste time and resources. This is a good example of wasting time and a bad process.