Re: Possible bugs in log -g

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.

-Hyrum (who really is open to suggestions :) )