Thank you for your response,
The problem with keeping a versioned list of bugs in a file is that it
only allows you to update the list in the revision that relates to the
day you found the bug, and not the day you caused the bug.
Example:
The head of /trunk is at revision 500, I have three branches A, B and C
taken from revisions 50, 100 and 150 respectively of the trunk. Now
during testing I discover a bug BZ123 that was introduced at revision
100 so I update the bug list file in branches B and C; this works fine
until I decide to create another branch from revision 125, BZ123 is not
in my bug list text file at revision 125 so I would need to examine the
head bug list file and copy across the bug numbers that are relevant.
I'm not saying your system will not work, but when you take into
account, merging and reverting etc. it all becomes a headache for the
maintainer.
I did initially consider a simple text file but rejected it for the
above reasons. Please let me know if I've misunderstood your
suggestion. After all I'm looking for the simplest solution.
Jonathan.
On 13/01/2011 18:20, Pablo Beltran wrote:
I think it will work but you don't need to change the commit message to
achieve that. You can create a plain text file (bug list) and versioning
it in Subversion.
For example, you may use this simple format:
.......
bug x: r1, r2, r3
bug y: r2, r7
.....
and look for revision numbers in the list instead of bug names.
Example:
"does bug x appears in branch y?"
It's the same that checking whether any revision number retrieved from
/svn log "branch y" /is present in the record for the "bug x" (r1,r2 or
r3 in the example).
I think that writing that script is also quite simple and the solution
more maintainable and traceable. I think (not sure) that changing commit
messages is out of version control scope and you would loss traceability
with your solution: today you may think that "bug x" was introduced in
r1 and appears in "branch y". Next week, you might discover that "bug
x" was really introduced in r2 and then appears in "branch z" but not in
"branch y". Sou you should change again the comment for r1 to reflect
that really it was not the introduction of the bug. If you forget do it,
surely next moth you will try to fix a bug on "branch y" which was not
affected by the bug.
I have another question. Would you need to answer "where does bug x
appears?"
Pablo.
On Thu, Jan 13, 2011 at 5:46 PM, Jonathan Oulds
<jonathan_ou...@mcafee.com <mailto:jonathan_ou...@mcafee.com>> wrote:
Hello,
Currently we track bug fixes by including a reference number within
the commit message, I'm sure this is common practice.
However we would also like to keep track of the revision where bugs
were introduced. As a use case, consider a project with many
branches and tags, now imagine that a bug is discovered to have been
introduced at an early stage of the project e.g. revision 100. All
branches taken after revision 100 will potentially have the bug all
branches taken prior to revision 100 will not. The problem here is
that as the number of bugs and branches increase the job of
answering the question "does bug x appear in branch y?" becomes ever
more difficult.
As a possible solution we are considering modifying commit messages
to indicate the bugs introduced in each revision. It should then be
possible to answer the above question with a simple svn log + grep.
I would be interested to hear any feedback the community has on this.
Jonathan Oulds
