Mark Phippard wrote:
> I just updated to HEAD to try the updated blame -g support. As usual,
> I am using the merge tracking sample repository I have created which
> is described here:
>
> http://merge-tracking.open.collab.net/servlets/ProjectProcess?documentContainer=c2__Sample%20repository
>
> I emailed Hyrum an updated version of the dump file to test with.
>
> When I made the same repository, I always did copies with a username
> of "copier" and merges with a username of "merger". That way, I knew
> I should never see those names in the blame output. It also make it
> easy when looking at log -g.
>
> For the most part, it is all working perfectly. There is just one
> file where it does give the right results.
>
> $ svn blame -g trunk/products/index.html
> 1 user <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
> 1 user "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
> 1 user <html>
> 1 user <head>
> 1 user <meta http-equiv="Content-type"
> content="text/html; charset=utf-8"/>
> 1 user <title></title>
> 1 user </head>
> 1 user
> 1 user <body>
> 1 user <p>Content for merge tracking early adopter program</p>
> 1 user
> G 2 user <p>This is the index page in the products folder.</p>
> 1 user
> G 12 merger <p>At our company we have 3 products:
> G 2 user Big
> G 12 merger Medium
> G 2 user Little
> G 2 user </p>
> 1 user
> G 11 auser <p>Check out our new roadmap!</p>
> 1 user
> 1 user <p>List of children:</p>
> 1 user <ul>
> 1 user <li>--</li>
> 1 user </ul>
> 1 user
> 1 user <p>Copyright 2007, CollabNet</p>
> 1 user </body>
> 1 user </html>
>
> You see those revision 12 = merger lines in the output? Those should
> not exist. If you look at the diagram in the document I linked to,
> those lines of code were all changed in r9 on trunk. They should have
> gone into /branches/b when it was created from trunk at r10. In r12,
> /branches/a is merged into /branches/b. I did diffs of all the
> revisions to make sure the output is correct. There is just something
> about this scenario that is giving throwing off the blame output.
Just letting folks know that I'm looking into this. I think the
solution should be straightforward given the current architecture.
("Really, how hard could it be?")
> Actually, looking again, the lines for revision 2 are also wrong in
> that they indicate it is a merge. Really just the 1-line marked as
> r11 should show as being the result of a merge.
r29077 fixed this problem (though I'm still confused as to why there
were duplicates to begin with).
-Hyrum
Received on 2008-01-30 19:23:34 CET