[email protected] wrote on Tue, Dec 20, 2011 at 13:40:03 -0800: > http://subversion.tigris.org/issues/show_bug.cgi?id=3862 > > > > > > > ------- Additional comments from [email protected] 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@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: > [[email protected]].
