4

I was wondering is there any software, that integrates ticketing system(or bug tracking) with SVN, but in a specific way. I want to prohibit any code changes, that does not have ticket (or bug id).

For example:

  1. Each developer has read-only access to SVN - he can update sources, but can not commit.
  2. Each commit must contain Bug/ticket id
  3. Even for optimization tasks, developer must create ticket for himself and then implement some stuff

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

I don't have any environments for ticketing system (I can use Trac as well as BugZilla or any other), but there must use SVN as a code repository.

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

Sebastian Łaskawiec
  • 2,667
  • 15
  • 33
  • What exactly is the purpose of that policy? It seems like it just creates busy work - wouldn't it just be better to make policy and review if people are following it than forcing some strict rule? Eventually what you'll get is a bunch of useless, empty cases/issues/bugs that have no content in them - they exist only for a reference number so someone can commit something to the repository. You are just moving the issue from one place to another and creating a mess along the way. – Tim Jan 04 '11 at 15:09
  • Hi Tim, yes, you are right, however in case of maintain-only projects, development team work mainly on creating small add-ons and resolving bugs. In such cases having bugs and corresponding code changes in one place might be a good idea. – Sebastian Łaskawiec Jan 04 '11 at 17:32
  • You can integrate very easily and I think that is a good idea - I use that for all my projects and at work, but the problem is with the "prohibit any code changes". That sounds like a really bad idea. – Tim Jan 04 '11 at 17:52
  • Yes, in the matter of fact it is. However in my approach I always need to have a link from requirements to code and in opposite direction. To assure this, I would need to prohibit code changes (without ticket), because there would be no such connection. – Sebastian Łaskawiec Jan 04 '11 at 18:01
  • Yes, but the workaround for people would be to create a useless ticket that had nonsense in it just to commit code. So rather than solve the problem you just moved it and made life worse for everyone. It is better to just watch the commits/changes to branches that need it and/or institute code reviews/promotions. – Tim Jan 04 '11 at 18:51
  • 1
    This is also useless because even if you had hooks on the svn side, users could just put in an old/unrelated ticket number to do the commit. Again, you're not really solving anything this way. The answer is educating your developers and making your process work, not instituting some unbendable rule. – Tim Jan 04 '11 at 18:53
  • A long time has past since this post and we now have a solution: http://www.asitrack.com. It's a native bug tracker with built-in Subversion integration. – Cosmin Aug 06 '14 at 10:52

3 Answers3

3

I've been using TFS recently. That has the capability to set up a similar workflow - you have to create "work items", to which you can attach bugs, to which you can commit changes. It's impossible to commit without first creating a bug, without first creating a work item.

It sent me crazy and I changed the settings, because my workflow went like this:

  • Happily editing code to fix a bug.
  • Spot another, unrelated bug.
  • Commit code changes to first bug.
  • Stop flow and fire up work item editor.
  • Figure out VS2010's horrible work item UI and create a new work item.
  • Figure out VS2010's horrible bug tracker and create a new bug.
  • Return to the code.
  • Work out where the second bug was.
  • Fix second bug.
  • Return to working on the original bug.

Actually, my workflow went more like this:

  • Happily editing code to fix a bug.
  • Spot another, unrelated bug.
  • Think to myself, "Fixing that line of code will take me a good hour of fiddling with obtuse bug trackers. Screw it.".
  • Carry on working on the original bug.

The overall effect is that bugs I could have fixed in no time at all remained in the system because I wasn't going to waste my time on absurdly bureaucratic bug reporting systems. What's more important to you - happy, productive developers, or impressive-looking reports pulled from SVN?

Ant
  • 4,890
  • 1
  • 31
  • 42
3

For this kind of policy you have to write a Hook Script which checks if there is a ticket id in the log message and of course check if the ticket id belongs to the appropriate project. Furthermore you can use things like Redmine as a ticket system.

khmarbaise
  • 92,914
  • 28
  • 189
  • 235
  • Yes, it is almost what I've been searching for. I think that the easiest way if to find proper implementation of IBugtraqProvider SVN interface (http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-ibugtraqprovider.html). I'll take some time and experiment with some issue tracker. Thanks for this hint. – Sebastian Łaskawiec Jan 04 '11 at 18:31
  • Sorry to say but you have to implement a Hook script on the server side not on the Client side. – khmarbaise Jan 04 '11 at 19:33
  • Yes I think that's it. I found several SVN plugins and tutorials how to create hook scripts of Google. In my opinion this answers my question. Now I have to experiment a little and get svn and ticketing software working together. Thanks! – Sebastian Łaskawiec Jan 05 '11 at 20:16
0

If you really want to you can take a look at gurtle, a plugin for tortoise that allows users to bring up a list of bugz. Following that template you can offer a way to quickly and easily create a case/issue if there isn't one.

Aside form that I have to say I think your goal is wrong-headed and counter-productive. Some well-meaning processes/policies sound good sometimes, but in practice end up being a nightmare and wastes of time and resources. This is a good example of a waste of time and bad process.

Tim
  • 20,184
  • 24
  • 117
  • 214
  • Hi Tim, It seems that Gurtle work only with Google code issue tracker. I was thinking about something already written. However Gurtle code seems to be easy to change, so it is worth to consider. Thanks for this hint. – Sebastian Łaskawiec Jan 04 '11 at 17:56
  • on second thought, this is not good, because it requires all developers to install the plugin and also doesn't work for non tortoise clients. – Tim Jan 04 '11 at 18:59