Okay, I see what you are driving at here.
We write a script that takes the branch URL plus the buglist file, the
script performs an svn log -g -v to get a list of all the revision
numbers that went into that branch then compares those against the head
revision of the buglist file.
Yes, that is a nice solution. I believe it is analogous to what I
originally proposed, but without the need to modify the commit message.
Thank you
Jonathan
On 14/01/2011 10:21, Pablo Beltran wrote:
Where is the bug file versioned? I think that is the point. In my
opinion it should not be versioned across branches because that would be
a headache. Hence it should not be placed under the trunk and you might
create a new directory "bugs" at the same level that trunk, tags and
branches. In that way, you will not create new versions of the bug file
every time the trunk is copied.
In your example, the content of the file (.../project z/bugs/list.txt )
would be:
.................
BZ123: 100
.................
all the time (until other bug is found and the bug list is updated)
You would get these results after executing the script:
bug_finder.sh A (<- Nothing)
bug_finder.sh B (<- Found bug BZ123 at r100)
bug_finder.sh C (<- Found bug BZ123 at r100)
bug_finder.sh D (<- Found bug BZ123 at r100) (This is the branch created
at r125)
That would happen because the r100 belongs to the log of B,C and D but
not A.
Normally, you would use the HEAD revision of the bug file. But you have
also the history of your bugs (log of the bug file) what might be very
helpful.
On Fri, Jan 14, 2011 at 10:26 AM, Jonathan Oulds
<jonathan_ou...@mcafee.com <mailto:jonathan_ou...@mcafee.com>> wrote:
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>
<mailto: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
