Create 2 custom fields 1) one of type integer labeled "Introduced in" 2) one of type integer labeled "Fixed in"
someeone must be in charge of determining when the bug whas introduced and fixed ... you can then do your searching if you wanted to get snazzy, write a plugin so that it auto displays those as trac links to revision numbers. -Chris On 7/3/07, John Clayton <[EMAIL PROTECTED]> wrote: > I should make myself clear when I use my mother tongue, English. > > What I mean by 'output created' is a build, and a build for me is strongly > related to a subversion repository value - i.e a point in time. > > > Thanks > > -- > John Clayton > Development > FileWave, Switzerland > Tel : +41-71-914-3084 > > > > > On 3 Jul 2007, at 15:21, John Clayton wrote: > Yes, this is what I'm getting at too - an effective way of tieing 'work > done' to 'output created', in this case 'work done' is all the code changes, > ticket modifications, documentation, testing etc and in my case 'output > created' is a subversion repo number. I see the repo number as being a very > stable way of defining a fixed point in time - and if there was a way I > could easily extract 'work done' between two repo numbers, I'd be 90% happy! > > > Thanks > > -- > John Clayton > Development > FileWave, Switzerland > Tel : +41-71-914-3084 > > > > > On 3 Jul 2007, at 14:53, [EMAIL PROTECTED] wrote: > > > Hello All, > > this is very similar to what was discussed in [1]. In my opinion a > post-commit hook helps to solve the problem. But trac could do a lot > more if it would understand the linage of the version numbers and the > layout in the archive if it would deeper integrate into subversion, e.g. > > 1.) automatically tell you which bugs are still open in different branches > 2.) which bugs have been fixed between two different versions / revisions > 3.) Have a closed state "fixed in next version" and trac would fill out > the version the version when the milestone is closed. > 4.) Build a full "Release Notes" documents for all bugs in all predecors > of a specific version > 5.) As a real integration show stopper, you could have an option in the > svn client (e.g. tortoiseSVN) to choose from a list of possible tickets > during your commit for a specific branch. But this is dreaming > > A post-commit hook and some custom fields can give you parts of this. > > Best regards > Dirk > > [1] > http://groups.google.com/group/trac-dev/browse_thread/thread/47348243d5a98954 > > > > Emmanuel Blot schrieb: > You can use the trac+svn commit jook scripts to tie tickets to SVN > revisions. > It requires your developers use some dedicated syntax in their commit > log message, but it works smoothly. > > Check out the scripts in Trac /contrib. > > HTH, > Manu > > On 7/3/07, John Clayton <[EMAIL PROTECTED]> wrote: > > > Hello All, > > Background: > ----------- > Recently we've set up Trac+SVN to replace our ageing CVS > environment. We build our products so that they have a build number > in them, and we're thinking of changing this so that the build number > is simply the subversion repository number (a change that I think is > natural and intuitive). One of the support guys came up to me today > and said 'how do I find out what the changes we're in a particular > build?'. > > I know: there are many ways to solve this particular problem - I'm > trying to find out if there is a way I can solve this using Trac. > > The Problem: > ------------ > What we'd like to be able to do is somehow extract all of the tickets > that relate to a particular build number, or relate to a range of > build numbers. E.g. show me all the tickets that relate to build > 1190 (i.e repo number 1190). > > The requirement comes about because when we set up our systems for > testing, we need to know specifically what must be heavily tested in > addition to the regression tests being performed, it's also helpful > for our support staff - since they don't want to be manually > searching the Trac tickets DB to dig this information out by having > to read through each ticket to see if it relates to a particular build. > > My Thoughts: > ------------ > There's no specific relationship between a ticket and a build - so I > can't just write some SQL to create a report. There is a > relationship between a Milestone and tickets of course (which is why > I was thinking of pulling all the tickets for a build), so I can get > a list of tickets related to a milestone, but the milestone bears no > relationship to a build - and in reality I might have multiple > milestones that relate to a single build 'goal'. > > Perhaps I am bending the intention of Trac too much? I believe Trac > sees the world from a 'milestone perspective' anyway. > > My Question: > ------------ > Are there any plugins or other software that would provide an answer > to this kind of question? I've seen only the WebAdmin plugin, and no > others - so any pointers to things that might be let me reach my goal > would be greatly appreciated. > > Thanks > > -- > John Clayton > Development > FileWave, Switzerland > Tel : +41-71-914-3084 > > > > > > > > > > > > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~----------~----~----~----~------~----~------~--~---
