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

Re: [Issue 3862] 'svn blame -g' algorithm is flawed for merged revisions

From: Daniel Shahaf <danielsh_at_elego.de>
Date: Wed, 21 Dec 2011 00:07:54 +0200

cmpilato_at_tigris.org wrote on Tue, Dec 20, 2011 at 13:40:03 -0800:
> http://subversion.tigris.org/issues/show_bug.cgi?id=3862
> ------- Additional comments from cmpilato_at_tigris.org Tue Dec 20 13:40:03 -0800 2011 -------
> I agree -- the algorithm does seem busted. It doesn't make sense to naively
> interleave the mainline revisions with the merged ones. I'm not quite settled
> on an alternate recommendation, though.

[ Context: the 'blame -g' algorithm for computing the revision blamed
  for a given line with merges accounted for; see:
  http://subversion.tigris.org/issues/show_bug.cgi?id=3862#desc3 ]

Would the following work:

- Input: (src='/trunk/iota', victim='/branch/iota')
- Algorithm:
  - blame VICTIM normally
  - blame SRC_at_N normally, where N is the last revision of SRC merged to VICTIM
  - diff the two blame chains
    (i.e., use the existing libsvn_diff, but each logical line would be
    a (blamed revnum, physical revnum) tuple)
  - when the diff changes the assigned revnum but not the line's text,
    use the smaller of the two revnums

Note that I'm assuming that we have a SRC argument --- which isn't how
'blame' works today. I also haven't worked much on 'blame' before, so
standard caveats apply.

> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=463&dsMessageId=2895209
> To unsubscribe from this discussion, e-mail: [issues-unsubscribe_at_subversion.tigris.org].
Received on 2011-12-20 23:08:58 CET

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