New bug in log -g with 1.5.1

[Mark Phippard <ma...@gmail.com>]

I think the new log -g code in 1.5.1 has added a new bug.  In our
1.5.x branch run this command:

svn log -g -c32253

The bug I am seeing is when we create a feature branch, merge it to
trunk.  Then later merge trunk to our release branch.  When we run log
-g, all starts off well.  It shows the merge from trunk, and then
shows that those trunk changes were merges from the feature branch.
Where it then veers into what I think is a bug, is that it then
repeats those changes from the feature branch.  It makes it look like
you merged directly from the feature branch to the release branch.

I am attaching a screenshot of how Subclipse shows the above change.
I think it illustrates it better.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: New bug in log -g with 1.5.1

["C. Michael Pilato" <cm...@collab.net>]

Mark Phippard wrote:
> I think the new log -g code in 1.5.1 has added a new bug.  In our
> 1.5.x branch run this command:
> 
> svn log -g -c32253
> 
> The bug I am seeing is when we create a feature branch, merge it to
> trunk.  Then later merge trunk to our release branch.  When we run log
> -g, all starts off well.  It shows the merge from trunk, and then
> shows that those trunk changes were merges from the feature branch.
> Where it then veers into what I think is a bug, is that it then
> repeats those changes from the feature branch.  It makes it look like
> you merged directly from the feature branch to the release branch.
> 
> I am attaching a screenshot of how Subclipse shows the above change.
> I think it illustrates it better.

We decided prior to 1.5.0 that 'svn log -g' would not be in the business of 
trying to interpret the deeper meanings of changes to mergeinfo.  It would 
simply following mergeinfo changes to the places they lead.  In r32253, the 
root of the branch had mergeinfo that changed like so:

    Merged /trunk:r32153,32160,32185,32237
    Merged /branches/issue-3220-dev:r32136-32152

It's that second set of changes that cause the redundancy you see.  And this 
isn't a problem new to 1.5.1 -- 1.5.0 did the same thing.

I don't think we'll ever get this "right" unless we grow a bullet-proof way 
to distinguish between mergeinfo that was created by the *act* of a merge 
versus that which is delivered to a branch as part of the *content* of the 
merge.

-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand