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

Re: Merge Tracking Auditing - SoC

From: Daniel Rall <dlr_at_collab.net>
Date: 2007-04-17 02:30:03 CEST

On Mon, 16 Apr 2007, Hyrum K. Wright wrote:

> Hello all.
> As many of you know, the approval for Summer of Code projects came last
> week, and I've received funding to work on the auditing aspect of merge
> tracking
> (http://subversion.tigris.org/merge-tracking/func-spec.html#commutative-author-and-rev).
> I'm excited to get going on the project.

Congrats! This is going to be fun.

> Over the next month, I'd like to finalize the functional spec at the
> above URL. I would appreciate it if people could take a look at it and
> suggest any changes. The pending questions in the spec, with varying
> degrees of relevancy, are:
> * How will --merge-sensitive behave for commits which remove merge info
> (e.g. reverts)?

We should trace back to the original author (pre-reverted commit). If
Alice makes a commit to code previously modified by Bob (committed
with no merge history), and Alice's commit is subsequently reverted by
Chris, we should show Bob as the author. If Bob's commit was itself
the result of a merge, we should recurse until we find a commit which
did not add merge info (the leaf node), and assume its author.

> * In the case of svn log, would the user be better served if we just
> included the original revision logs in line with the logs (i.e., no
> special indentation, etc.)?

A good case has been made for no indentation. Some indication of that
we're not showing the actual log message would be useful.

> * What about svn ls --verbose, which also shows revisions and usernames?

This use case should be supported, too. Will you add it to the spec?

  • application/pgp-signature attachment: stored
Received on Tue Apr 17 02:31:13 2007

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.