subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pablo Beltran <>
Subject Re: Modifying commit messages
Date Fri, 14 Jan 2011 10:21:53 GMT
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: A  (<- Nothing) B (<- Found bug BZ123 at r100) C (<- Found bug BZ123 at r100) D (<- Found bug BZ123 at r100) (This is the branch created at

That would happen because the r100 belongs to the log of B,C and D but not

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

> 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
>> < <>> 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

View raw message