Possible bugs in log -g

This is with trunk code as of r29411

Tests are using merge tracking sample repository.

Dump here:

http://merge-tracking.open.collab.net/files/documents/147/409/mergetracking.dump

Description here:

http://merge-tracking.open.collab.net/servlets/ProjectProcess?documentContainer=c2__Sample%20repository

I have the entire repository (17 revisions) checked out to make
testing easier. Here are some problems I see with the log -g code.

1) You only seem to ever get one set of merged revisions. For
example, when you run this command:

svn log -g trunk

The r17 revision triggers a lot of merge results (lots of which is
incorrect but I will mention later). When the log returns to the main
list of revisions it hits r14, r8 and r6 which all should show
follow-on merge information but do not. My guess is that there is
some code to only show a given revision once and the bug of r17
showing too much is filtering these out?

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.

3) Incorrect mergeinfo

svn log -g branches/b

r12 is a merge from branches/a It should expand to show r11 and does,
but it also includes r7. This is not correct. branches/b was created
in r10 and included r7 in its mergeinfo when it was created.
Specifically:

$ svn pg -r10 svn:mergeinfo branches/b
/branches/a:3-5,7

NOTE: Merge itself handles this correctly. r7 was a blocked revision
and merge correctly does not merge it to branches/b

There are other examples of problems, but I would guess that they are
all variations on whatever is causing these.

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