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

Re: Forward blame (was "svn blame" with a specified revision)

From: mark benedetto king <mbk_at_lowlatency.com>
Date: 2003-10-24 15:21:37 CEST

On Fri, Oct 24, 2003 at 09:58:11AM +0100, Colin Watson wrote:
> On Tue, Oct 14, 2003 at 10:24:23AM -0400, mark benedetto king wrote:
> > On Tue, Oct 14, 2003 at 12:16:49AM +0100, Julian Foad wrote:
> > > The reason for (X < Y) being an error is that it would introduce a
> > > confusion about which version of the file is to be annotated: FILE@X or
> > > FILE@Y. It would be possible to write a forward-looking annotator which
> > > says who was the next person to change each line of this old file, and, for
> > > that, "-rX:Y" (X < Y) would be appropriate.
> >
> > What a wonderful tool! "Who deleted the check for NULL?".
>
> I'd like to have such a tool, and it does seem to be reasonably easy to
> implement, too. I deleted the check for X < Y (which, BTW, says
> "preceed" when it should say "precede"), tweaked some of the rest of the
> logic a bit, and it seemed to work.

The typo is fixed in rXXXX. The check for X < Y is necessary because
it is necessary to receive the log messages in reverse chronogical order,
in order to traverse changed-path revisions correctly.

>
> I have a few questions about the details:
>
> * The "natural" implementation leads to all lines being displayed as
> "next changed" in the end revision unless they've been changed
> between start and end, just like normal blame displays all lines as
> last changed in the start revision unless they've been changed
> between start and end. It makes a lot less sense for forward
> annotation, though. What's the right solution?

I think the right solution is a different output_diff_modified callback
routine (or at least a flag in the baton) to have it accumulate blame
differently. You still need to process the diffs in chronological
order.

>
> * The "natural" implementation leads to all lines being displayed as
> "next changed" in the end revision unless they've been changed
> between start and end, just like normal blame displays all lines as
> last changed in the start revision unless they've been changed
> between start and end. It makes a lot less sense for forward
> annotation, though. What's the right solution?
>
> Really, you don't want to annotate a line with a revision unless the
> line was (a) actually changed in that revision and (b) in the range
> you're interested in. So how about we simply leave the revision and
> author columns blank unless the line has been changed in a revision
> Z where X<Z and Z<=Y?

It would also be nice if the normal blame didn't attribute all lines
to the start-rev, but in order to do that, we'd need to get the rev
before the start-rev. I'm sure that's possible, but I don't know how
off the top of my head. Given that change, and the change described
above, it should be straightforward to get the semantics you're looking
for.

>
> * Should it be simply -rX:Y with X < Y (actually, the current
> implementation seems to require -rY:X for this), or should there be
> an extra --forward option? It makes a difference when the question
> you want to ask is "who next changed this code after revision X",
> where the syntax would be either "-rX:HEAD" or "-rX --forward".

I prefer the --forward option; I think it would make user-error less likely.

--ben

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 24 15:22:19 2003

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.