[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

[PATCH] 'blame -g' revision ordering (was: Re: Problem with blame -g)

From: Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>
Date: Mon, 04 Feb 2008 09:36:51 -0600

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

The attached patch fixes this particular occurrence of the issue. But
I'm still a little unsure if the logic is correct. This modifies the
blame handler to prefer older revisions over newer ones for lines in
which the merged revision and the mainline revision differ. Previously,
we always chose the merged revision, but for identical lines of a file,
we want the mainline revision if it is older, because that reflects the
true author of the change.

Is this logic flawed?


Fix 'svn blame -g' revision selection, specifically the problem
identified by
markphip in this thread:

* subversion/svn/blame-cmd.c
  (blame_receiver): Instead of using the merged revision anytime to two
   revisions differ, choose the earlier of the two.

Received on 2008-02-04 16:37:06 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.