We use TortoiseSVN, but we have no bug tracking system. I know, lame, but beyond my control.

There were times when svn wasn't in daily use. Now I've had succeeded in pressing for using it regularly, with proper merging, branching, tagging etc.

As you could expect, the number of revisions increased in result, which makes browsing repository log a bit troublesome now.

I thought about utilizing some convention based on keywords ("[bugfix]", "[feature]", "[refactored]", "[minor]", "[merged-from-trunk]"... :) so as to make it more searchable.

It feels like reinventing the wheel, though. Is there any established convention for that? Or is my approach wrong from the beginning? Any better, alternative solution?

  • There is sort of a convention for commit message in git stating that it should begin with a short line of less than 50 chars (as some tools generate email subjects from that). Maybe there is more. Just a thought.
    – scarfridge
    Commented Apr 26, 2012 at 10:42
  • 1
    "beyond my control" - download a free bug tracker, set it up, use it. Even if testers/users won't add bugs to it, you still can.
    – ozz
    Commented Apr 26, 2012 at 10:57
  • 2
    @Morawski - where exactly did I say it would be hosted in the cloud? I said "download". I don't think a ticket based system SHOULD replace a bug tracker, they should be totally seperate, as they do different things, manage SLA's for example. You SHOULD have a seperate bug tracker though.
    – ozz
    Commented Apr 26, 2012 at 12:18
  • 1
    @Morawski that would be a different question and probably a pretty good one
    – gnat
    Commented Apr 27, 2012 at 12:49
  • 2
    @Morawski are you trolling?? Or are you just drip feeding info? I don't believe that you cannot envisage having a bug tracker installed on a server and having multiple people use it. So that together with your cloud comment makes me now think you are not on same network as your colleagues? do you all work from home? Is that why you think it would need to be cloud?
    – ozz
    Commented Apr 27, 2012 at 13:38

2 Answers 2


If you have a unique ID for bugs or tickets, then a common pattern is to add #123 to a commit message if it fixes the bug with ID 123 or implements feature 123.

Oftentimes bug trackers have commit hooks that will add the commit log in the bug tracker or ticketing system based on this 'tag'. That allow you to find commit logs 'in context'

Also, did you search open source repositories to find common patterns for other scenarios? You could search Github for project of the same type and/or platform to see if there's a common denominator when people are merging or fixing bugs.


When we're doing stuff that refers to external problem reports (eg, via RT or whatever) we often end up with the string "fixes RT#12345" or similar if it's a bugfix.

For everything else, we often end up using Trac (which integrates nicely with an SVN repository) and provides roadmaps, wikis (for documentation etc), a bug tracking system, and a syntax/diff highlighted revision browser/search facility.

One thing this does is integrate a type of Wiki formatting with changeset revisions, including (most importantly and relevantly here) applying wiki formatting to the bare text of the changeset log. As a result, you can put wiki formatting in the commit message and have it do things like link to the correct branch revisions you're merging, or linking to the bug tracking systems actual bug report.

Eg, if there's a bug in the trac system that a revision changes we say "fixes #124" and when you browse that changeset via trac it will actually turn "#124" into a link to bug #124. Similarly if we say "merges [37:54/branches/featurex]" it turns it into a link to the source browser for /branches/featurex showing changesets between revision 37 and revision 54, with the option to select first and last and just show all changes between start and end revisions.

There's more info on the kind of internal links you can make in checkins here:


Hope that helps!

Your Answer

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

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