1

We have a scenario where we are advised to create a new SVN tag for every change request (which will be one every two weeks as it's an agile project) and link it to Clear Quest, so that in future for auditing purposes, one can look at the ticket, click on the tag URL and see what has been changed in browser window (our SVN server is hosted on VisualSVN).

Wouldn't it be a maintenance nightmare? In a six months span we'll be looking at 12 tags and could quickly grow more in case of emergency releases)

I would like to know the best approach to this issue. The issue again is:

Provide SVN Change Set in Clear Quest as a link without having to create a zillion tags.

Is it possible to create links with revisions on trunk so that one can click on it and directly view the change set in browser?

Thanks for looking into this.

savv'y
  • 219
  • 1
  • 10

1 Answers1

1

First of all it sounds like what you really want to do is have some sort of integration between your issue tracker and SVN. How you go about doing that depends on your issue tracker which based on your tags I'm guessing is jira.

Here's some info on how to integrate JIRA with SVN: https://confluence.atlassian.com/display/JIRA/Integrating+JIRA+with+Subversion

Generally how such integrations work is you include something in the commit message mentioning the issue you're addressing. Another alternative is revision properties, but that's probably a little more tedious.

Outside of that to answer your original question. You may want something like viewvc: http://www.viewvc.org/

Which gives you a nice web interface. For example at the ASF we have URLs like this that redirect to the viewvc view of the commit: http://svn.apache.org/r1460019

Which we can then embed in emails, issue trackers, etc...

Ben Reser
  • 5,695
  • 1
  • 21
  • 29
  • Sorry I suppose I wasn't clearer. The problem I have is to provide SVN changes that are going in the ticket as link in CQ description not the other way around. – savv'y Mar 22 '13 at 23:29
  • 1
    Well all you really need is to list the revisions you need (if you want a pretty view of your changes to link to you'll need something like viewvc). If you're going to need a lot of revisions you're probably better off using a feature branch for that. – Ben Reser Mar 22 '13 at 23:32
  • My bad I didn't read through the apache link you've provided in your answer. Of the two approaches, which one do you prefer – savv'y Mar 22 '13 at 23:42
  • 1
    I'd say use a combination. If the issue is tiny and you only need a single change just use a link to a single rev. If the issue is going to take several changes and is far from trivial, create a feature branch. Also when you merge the feature back onto whatever you're trunk or whatever branch you're working on you'll end up with a single rev, which you can think also just link in the issue tracker. Once you've merged back (reintegrated) then you can delete your feature branch because you don't need it anymore. – Ben Reser Mar 22 '13 at 23:49
  • I'm not clear what you mean by tag here. Subversion's tags are really not different than branches, a tag is only different because you chose not to commit to it (though you can enforce that with hook scripts). I'm having trouble envisioning how a tag really helps you. Because it sounds to me like you want to describe the changes that went into implementing the change request. A tag is just a copy of the code at a single point in time. In order to describe the changes you need to describe what changed from point A to point B to implement the change. – Ben Reser Mar 22 '13 at 23:59
  • While you have trouble envisioning how tags would help me, It became clearer that the approach proposed to use unique tags for each change request and then someone would view history of it to find out the changes sounds absurd. Thanks for the help and marking this as answered. – savv'y Mar 23 '13 at 00:05