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_at_mcafee.com <mailto:jonathan_oulds_at_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_at_mcafee.com <mailto:jonathan_oulds_at_mcafee.com>
> <mailto:jonathan_oulds_at_mcafee.com
> <mailto:jonathan_oulds_at_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
>
>
>
>
Received on 2011-01-14 13:40:53 CET