Re: Possible bugs in log -g

On Feb 18, 2008 5:35 PM, Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu> wrote:
>
> Mark Phippard wrote:
> > On Feb 18, 2008 4:43 PM, Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu> wrote:
> >> [I'll look at all the problems, but I wan to take them one at a time to
> >> avoid possible dependencies.]
> >>
> >> Mark Phippard wrote:
> >> ...
> >>> 2) Too much mergeinfo. Incorrect filtering?
> >>>
> >>> svn log -g -r17 trunk
> >>>
> >>> This should really just show r16, but winds up showing a ton more.
> >>> r15 gets pulled in and this was a big synch up merge from trunk. So
> >>> this should get filtered out.
> >> I get the following:
> >> $ svn pg svn:mergeinfo trunk/
> >> /branches/a:3-11
> >> /branches/b:10-13
> >> /branches/c:5-16
> >> /trunk:2
> >> $ svn pg svn:mergeinfo trunk/@16
> >> /branches/a:3-11
> >> /branches/b:10-13
> >> /trunk:2
> >>
> >> And the mergeinfo diff as detected by 'log -g' is '/branches/c:5-16',
> >> which is correct, and that's the history that it is tracing. Maybe you
> >> could help me understand why should we not pull in everything, all of
> >> 5-16. If we should stop somewhere, how do we tell when to stopping
> >> tracing history?
> >
> > I saw the same history, and I do not really know the answer. Clearly
> > the current output is wrong (in my opinion). /branches/c only has
> > three points of history.
> >
> > r5 branch was created from /trunk
> > r15 branch was caught up with changes on /trunk
> > r16 a change was made
> >
> > I would assume r5 and the information it brings with it should be
> > pretty easy to exclude.
> >
> > r15 is the real question. I guess you would have to see that r15 was
> > a merge that came from the same location you are checking the logs
> > for, and know to exclude it.
> >
> > Put another way. If I were looking at the history of /branches/c I
> > would expect it to show r15 and what that revision merged into the
> > branch. But when looking at the history of /trunk, it seems wrong to
> > show the revisions where something happened on the branch that came
> > from trunk.
> >
>
> I agree that r15 is where things get interesting. In my opinion, r15
> should still show up, along with merges which it brought in. The
> mergeinfo diff for /branches/c_at_15 is:
> /branches/a:3-11
> /branches/b:10-13
> /trunk:2,5-14
>
> The /trunk path does get filtered out properly, because we recognize
> that it is part of the original history for the object, so we don't
> follow it. We follow the /branches/a and /branches/b mergeinfo as we
> would any other merged paths. Even though it appears that we are
> treating /trunk_at_14 specially, that's not entirely true. Unfortunately,
> I don't know that we have a mechanism to determine which of the three
> paths the merge originated from, just that it changed in the specified way.
>
> I have the opinion that we should include r15, for completeness. It is
> a bona fide change on the branch, which has been merged in, so we should
> display it. Given the data we currently store, I don't even know that
> filtering it out is an option.

All I can say is that it looks really wrong to me. As for the
information, one of the changes Kamesh had made on his issue-2897
branch was to capture exactly what was merged in a revision, as
opposed to the diff of the mergeinfo property which also includes
changes to the property that came as part of the merge.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org