Hello Christopher, > A custom field that has the source of the bug would work for this .... > you could then specify > source:/trunk/componentname/classfiled@<revision>#L<linenumber> > and then you could write a report for them that takes as input a path > and then searches for all tickets whose aforementioned custom field > begins with the input path > Thanks for the tip, I will try this out. Possibly this can be done automatically with a post-commit hook script??? Need to think about this a little further.
> not sure how a hook script can help you here .... you need to know > what lines of code the bug was *found* in. However, this would deff > help you determine what lines of code were modified to fix a bug ..... > I thought about parsing a commit message like "fixd bug #xxx introduced in [1234]" and that together with the checkin path this will automatically combine the revision with the ticket. > to me that sounds more like a policy issue than a trac issue. A > suggestion if I may ... use the version number to determine what > version the bug was found in (could be N/A for an anhancement) and > assign it against the milestone for trunk (or the maintenance of a > released version if that's a higher priority for you .... just pick > one and be consistent). That is what we currently do. But it still has the problem, that we can not tell which bug exist in which version. E.g. if you find a bug in the trunk, and you can pinpoint the bug to a revision prior to a branch this bug is also in the branch, until you proof the opposite. This is one of the nice automatic information you could get out of subversion. Cloning tickets or having a close policy is only a manual task around organizing the data. But currently you can not tell from all entered data, which bugs you can expect in a specific version. Look from a service side. The service team reports an issue in a specific version of the software. The develeopment team will assign the issue to a specific revision. From now on, the service team could query for all known issues in a specifc version and they will get this information automatically, without additional human intervention. They would also know automatically, whether the bug is fixed in this maintenance line or not. This needs to be combined with the understanding of "linage". I isn't of a great help to click through all possible predecossors of a version in order to get the information. > Make your changes and then merge them across > branches, only closing the ticket when the changese has been merged > into all appropriate codelines. The implication here is that a ticket > is not closed until it has been merged across all appropriate > codelines. This may save you some headache later on .... > This is one workaround for the problem. > our policy is to not have future versions ... we only have milestones > and released versions ... that helps out a lot with the dilema you > describe (we faced that one too). For us, all future versions are > stored as milestones but not all milestones are future versions. This > methodology is of course eagerly awaiting the ability for milestones > to have dependencies. > Yes, one milestone can be dependent or include another milestone, e.g Installation at a customer side will need a specific version of the software. Milestones also have a workflow behind them, so actually milestones should be nothing else than another ticket type ;-) > ahh ... so your talking more about linage rather than versions .... > interesting concept. > Yes, that was what I meant. Sorry for not beeing precise about this. > we are playing around with the same thing ... we created a ticket type > called requirement and a ticket type called test case .... leads to > some good tracability .... combine this with the graphviz plugin ... > sick!!!! > dreaming, if I only could help. But I'm completely booked out with job/family and my involvement in the vss2svn [1] converter (sorry for self advertising another open source project ;-) ) Dirk [1] http://www.pumacode.org/projects/vss2svn --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to trac-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
