You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Jonathan Oulds <jo...@mcafee.com> on 2011/01/13 17:46:00 UTC
Modifying commit messages
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
Re: Modifying commit messages
Posted by Jonathan Oulds <jo...@mcafee.com>.
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_oulds@mcafee.com <ma...@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_oulds@mcafee.com <ma...@mcafee.com>
> <mailto:jonathan_oulds@mcafee.com
> <ma...@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
>
>
>
>
Re: Modifying commit messages
Posted by Pablo Beltran <pa...@svnflash.com>.
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
<jo...@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_oulds@mcafee.com <ma...@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
>>
>>
>>
>
Re: Modifying commit messages
Posted by Jonathan Oulds <jo...@mcafee.com>.
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_oulds@mcafee.com <ma...@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
>
>
Re: Modifying commit messages
Posted by Pablo Beltran <pa...@svnflash.com>.
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
<jo...@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
>
>
Re: Modifying commit messages
Posted by Jonathan Oulds <jo...@mcafee.com>.
We do use Bugzilla to track issues, you are correct that you can file
the bug against multiple branches and we do.
However, what if a branch is created after the bug has been added to
Bugzilla. Someone would have to manually inspect the revision at which
the branch was taken and create another set of Bugzilla issues for the
new branch for all the bugs that were present at that time of branching.
This to me seems to be the problem with issue tracking and branching,
keeping the two synchronised.
However, what if you could do an "svn log -g" and compare the results
with a Bugzilla search to prove that all known bugs were also present in
Bugzilla for that branch?
Jonathan.
On 14/01/2011 10:56, Thorsten Schöning wrote:
> Guten Tag Jonathan Oulds,
> am Donnerstag, 13. Januar 2011 um 17:46 schrieben Sie:
>
>> Currently we track bug fixes by including a reference number within the
>> commit message, I'm sure this is common practice.
>
> If you already use a bug tracker, doesn't that provide a mechanism to
> file bugs against multiple versions or maybe clone bugs into multiple
> versions? Bugzilla for example does the latter, at least in my old
> 2.22.x, which wouldn't directly answer the question which bug does
> span over multiple versions. But what you could do is create some
> master bug for your error and dependant bugs for each version in which
> this error occurs. At least you could use the reporting tools of your
> bug tracker.
>
> In my opinion, depending on the concrete bug and how important it has
> to be fixed and all that stuff, having more than one bug for the
> different versions is of benefit if you think of things like branches
> which aren't supported anymore and therefore don't need a bug fix,
> some need a fix but not now, for some branches this bug is a show
> stopper etc. I would use the bug tracker for such things.
>
> Mit freundlichen Grüßen,
>
> Thorsten Schöning
>
Re: Modifying commit messages
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Jonathan Oulds,
am Donnerstag, 13. Januar 2011 um 17:46 schrieben Sie:
> Currently we track bug fixes by including a reference number within the
> commit message, I'm sure this is common practice.
If you already use a bug tracker, doesn't that provide a mechanism to
file bugs against multiple versions or maybe clone bugs into multiple
versions? Bugzilla for example does the latter, at least in my old
2.22.x, which wouldn't directly answer the question which bug does
span over multiple versions. But what you could do is create some
master bug for your error and dependant bugs for each version in which
this error occurs. At least you could use the reporting tools of your
bug tracker.
In my opinion, depending on the concrete bug and how important it has
to be fixed and all that stuff, having more than one bug for the
different versions is of benefit if you think of things like branches
which aren't supported anymore and therefore don't need a bug fix,
some need a fix but not now, for some branches this bug is a show
stopper etc. I would use the bug tracker for such things.
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning
AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig
Telefon: Potsdam: 0331-743881-0
E-Mail: tschoening@am-soft.de
Web: http://www.am-soft.de
AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam
Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow
Re: Modifying commit messages
Posted by Jonathan Oulds <jo...@mcafee.com>.
On 13/01/2011 20:08, Ryan Schmidt wrote:
>
> On Jan 13, 2011, at 10:46, Jonathan Oulds wrote:
>
>> 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.
>
> That's not necessarily true -- a branch taken before revision 100 could still contain the bug, if the revision that caused the bug is later merged into that branch. So I'm not sure your proposal actually helps solve a problem. It sounds like the problem is identifying which branches contain a particular bug, and I'd say you have to test each branch -- check out the branch, build your software, run it, see if it exhibits the problem. Then merge the fix from trunk if it's needed.
>
>
My understanding of svn log is that you can use the -g switch to include
comments from the merge history.
Example:
I take branch A from /trunk at revision 50, later I introduce a bug at
revision 100 of /trunk at revision 200 I merge /trunk into branch A, now
at revision 500 I spot my mistake and amend the log entry for /trunk@100.
Now if I do svn log -g branches/A surely I will see the updated log
entry identifying the bug, because the -g switch pulls in the log
entries from the merged revisions including the amended log entry.
Jonathan.
Re: Modifying commit messages
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Jan 13, 2011, at 10:46, Jonathan Oulds wrote:
> 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.
That's not necessarily true -- a branch taken before revision 100 could still contain the bug, if the revision that caused the bug is later merged into that branch. So I'm not sure your proposal actually helps solve a problem. It sounds like the problem is identifying which branches contain a particular bug, and I'd say you have to test each branch -- check out the branch, build your software, run it, see if it exhibits the problem. Then merge the fix from trunk if it's needed.
Re: Modifying commit messages
Posted by David Weintraub <qa...@gmail.com>.
It's an intriguing prospect. I am assuming you're referring to the
revision where the bug was discovered. For example, I might have a
defect that's been in my system for years, but didn't know about it
until release 2.1.0 came out.
It's not hard to do, and may be useful. I've never done it myself. I'd
say give it a try and report back how it works. This is usually
something that the defect tracking system does quite well, but maybe
embedding this in the Subversion logs might prove useful.
--
David Weintraub
qazwart@gmail.com