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

Re: [merge-tracking] 'svn blame' auditing

From: Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>
Date: 2007-02-21 20:24:17 CET

Daniel Rall wrote:
> On Wed, 21 Feb 2007, Hyrum K. Wright wrote:
> ...
>> I've decided to investigate what needs to be done to implement 'svn
>> blame' auditing support. For those unfamiliar with the problem, the use
>> case is simple. Quoting [1]: "If you merge rN into a branch B, and rN
>> was committed by author A, then svn blame should show the changed lines
>> in B as last touched by A, even if the merge was committed by you and
>> you are not A. This must also work when merging a range of revisions
>> with different authors."
> Behavioral changes to 'blame' should be designed concurrently with
> changes to 'log', and probably 'status --show-updates' (and 'info'?).
> Basically, to any API/command that carries a user name.

Great. I'll start familiarizing myself with how these commands are
currently implemented.

> Once "how it's supposed to work" is defined, these changes can be
> implemented incrementally (though, once you've got the functionality
> for one command, it should be very easy to roll it out to others!).
>> Before I begin, though. I would like to know if
>> b) Anybody has any suggestions/recommendations as to where to begin.
> Let's start by zeroing in on a really solid definition how this is
> supposed to work. I'd volunteer to roll that into the func spec,
> while you're working on implementing it for the 'log' or 'blame'
> command.

That would be great!

I'm also interested in where best this functionality could be placed. I
tend to think that it should be added to libsvn_repos, to help
streamline the amount of data going back and forth between client and
server. My understanding may be incomplete, though.

> A few points to consider:
> - We should be able to get both the user name of the original
> committer and/or the user name of the actual committer. (The
> requirement needs to be reworded to reflect this.)
> - Should We provide an API/command-line switch for which names to
> show, rather than always showing both user names? I tend to think so.
> How would this (new?) switch interact with --verbose (e.g. for 'log')?

I think a new switch would be a good idea. If possible, I suggest that
we invent a switch with a single character shortcut. Such a switch is
likely to be used by several commands, and it may be used frequently.

> - If we only show one user name at a time, should it default to the
> current behavior of showing the actual committer's name, or the
> behavior suggested by the requirment of showing the original
> committer's name? I tend to think the former, to maintain backwards
> compatibility.

I also agree.

>> If all goes well, I hope to be able to start posting patches in the next
>> couple of weeks.
> Fantastic, Hyrum!

Thanks. Note that the time prediction is definitely a lower bound, not
a guarantee. :)

Relatedly, where can I find a concrete example of merge info usage, such
as fetching the merge info and doing something with it?


Received on Wed Feb 21 20:24:35 2007

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