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 <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2008-07-29 16:31:49 CEST