On Fri, Feb 23, 2007 at 06:54:04PM -0800, Daniel Rall wrote:
>
> > 'svn blame':
> > Two additional columns for each line, one with the original revision
> > number, and one with the original author of that line. Unlike other
> > commands, we do not need to worry about multiple source revisions,
> > because each line can have at most one author.
>
What should be done if the merge included revisions that were themselves
merges? Should those revisions be treated as "original" or is the problem
recursive? Should that question be answered on the command-line?
> Yup, but determine which of a merge's source revisions changed a line
> is going to be tricky.
>
Tricky. ("But can you do it?")
> >
> > Implementation
> > --------------
> > Each of the reporting commands, although separate, will need to access
> > the merge info in a similar way. The implementation will provide a
> > clean interface, so that all of the client APIs can access the reporting
> > logic. It is anticipated that most of this logic will live in
> > libsvn_repos, with appropriate parameters punched back through the RA
> > layer to the client.
>
I think that the blame processing should be done client-side, mainly
because that's where all of the work is currently being done.
svn_client_blame() already keeps the revision author and date around;
it could easily be modified to keep the merge properties, too (since
file_rev_handler gets prop diffs).
Additionally, it would be useful to keep track of the original line
number of each blame block.
Once all of the "apparent" blame has been assigned, the blame
blocks with revisions that have merge metadata need to be further
inspected.
To determine the "true" source of a particular line, a process
similar to the existing blame routine would need to be followed,
except rather than diffing against one historical revision at
a time, the system would need to diff against one merged revision
at a time.
To restate:
For each revision R of node N that is the apparent source of a
particular line of blame, if R is a merge revision then:
Let O represent the revision of N prior to R.
Let G represent the revisions of N merged in R.
Let M represent the manual changes performed in R.
Starting with O, apply the differences in G, keeping track of
the source revision of each change.
Either these changes yield the blamed line (in which case, we know
the "true" source), or they do not, meaning that the blamed line was
part of M.
If the problem is recursive (see above), then recurse. :-)
--ben
PS: it's been a long time since I've gotten into the source
so take all of the above with several grains of salt.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Feb 25 05:25:34 2007