You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Hyrum K. Wright" <hy...@mail.utexas.edu> on 2007/04/16 20:53:32 UTC
Merge Tracking Auditing - SoC
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.
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)?
* 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.)?
* What about svn ls --verbose, which also shows revisions and usernames?
Thanks, and I look forward to starting the implementation.
-Hyrum
Re: Merge Tracking Auditing - SoC
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
Hyrum K. Wright wrote:
> Mark Phippard wrote:
>> On 4/23/07, Hyrum K. Wright <hy...@mail.utexas.edu> wrote:
>>> 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.
>>>>
>>>> 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)?
>>>>
>>>> * 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.)?
>>>>
>>>> * What about svn ls --verbose, which also shows revisions and
>>> usernames?
>>>
>>> We've resolved these questions, but added one more:
>>> * What happens when svn status --show-updates has multiple original
>>> authors?
>> I think it should be handled the same as info and ls, which I believe
>> means no changes to current behavior.
>
> That sounds reasonable. If there are not dissenting opinions, I'll add
> it to the spec.
Done in r24817.
-Hyrum
Re: Merge Tracking Auditing - SoC
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
Mark Phippard wrote:
> On 4/23/07, Hyrum K. Wright <hy...@mail.utexas.edu> wrote:
>> 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.
>> >
>> > 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)?
>> >
>> > * 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.)?
>> >
>> > * What about svn ls --verbose, which also shows revisions and
>> usernames?
>>
>> We've resolved these questions, but added one more:
>> * What happens when svn status --show-updates has multiple original
>> authors?
>
> I think it should be handled the same as info and ls, which I believe
> means no changes to current behavior.
That sounds reasonable. If there are not dissenting opinions, I'll add
it to the spec.
-Hyrum
Re: Merge Tracking Auditing - SoC
Posted by Mark Phippard <ma...@gmail.com>.
On 4/23/07, Hyrum K. Wright <hy...@mail.utexas.edu> wrote:
> 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.
> >
> > 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)?
> >
> > * 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.)?
> >
> > * What about svn ls --verbose, which also shows revisions and usernames?
>
> We've resolved these questions, but added one more:
> * What happens when svn status --show-updates has multiple original
> authors?
I think it should be handled the same as info and ls, which I believe
means no changes to current behavior.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merge Tracking Auditing - SoC
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
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.
>
> 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)?
>
> * 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.)?
>
> * What about svn ls --verbose, which also shows revisions and usernames?
We've resolved these questions, but added one more:
* What happens when svn status --show-updates has multiple original
authors?
Any thoughts?
-Hyrum
Re: Merge Tracking Auditing - SoC
Posted by Daniel Rall <dl...@collab.net>.
On Mon, 16 Apr 2007, Mark Phippard wrote:
> On 4/16/07, Daniel Rall <dl...@collab.net> wrote:
>
> >> * 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?
>
> I think svn ls is the same as svn info and should not be supported.
> Given that a commit for a file could be the result of a merge that
> combined several revisions and authors, there is just no way to show
> that for a command like info or ls that needs to essentially show a
> single value.
>
> With svn blame, we are dealing with lines of code and each line will
> only come from one revision/author. With svn log, the proposal calls
> for expanding the output to show all of the log entries. I do not see
> any similar way to deal with this for info or ls.
Hmm, good point. We'd have to use some type of "multiple author"
indicator (e.g. ellipsis), which offers less value than showing the
author who committed the merge.
The spec should be explicit about this anti-case for both 'ls' and
'info'.
Re: Merge Tracking Auditing - SoC
Posted by Mark Phippard <ma...@gmail.com>.
On 4/16/07, Daniel Rall <dl...@collab.net> wrote:
> > * 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?
I think svn ls is the same as svn info and should not be supported.
Given that a commit for a file could be the result of a merge that
combined several revisions and authors, there is just no way to show
that for a command like info or ls that needs to essentially show a
single value.
With svn blame, we are dealing with lines of code and each line will
only come from one revision/author. With svn log, the proposal calls
for expanding the output to show all of the log entries. I do not see
any similar way to deal with this for info or ls.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merge Tracking Auditing - SoC
Posted by Daniel Rall <dl...@collab.net>.
On Tue, 17 Apr 2007, Hyrum K. Wright wrote:
> Daniel Rall wrote:
> > On Tue, 17 Apr 2007, Hyrum K. Wright wrote:
> >
> >> Daniel Rall wrote:
> >>> On Tue, 17 Apr 2007, Hyrum K. Wright wrote:
> >>>
> >>>> Daniel Rall wrote:
> >>>>> On Mon, 16 Apr 2007, Hyrum K. Wright wrote:
> >>>> ...
> >>>>>> * 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.
> >>>> I'm having trouble parsing that last sentence. Would you mind restating it?
> >>> If we decide not to show the *actual* log message used with a commit
> >>> (which would be consistent with what we're going to do for 'blame'),
> >>> some indication in the output of the *original* log message(s) that
> >>> they aren't the actual log message, and are being displayed in lieu of
> >>> the actual message, might be useful.
> >> So, basically something to the effect of: (the revision numbers below
> >> are somewhat bogus.)
> >>
> >> ------------------------------------------------------------------------
> >> r24602 | dlr | 2007-04-16 19:02:48 -0500 (Mon, 16 Apr 2007) | 3 lines
> >> === result of merge in r24678 ===
> >>
> >> * notes/merge-tracking.txt
> >> Add issue #2769, and sign up for it.
> >>
> >> ------------------------------------------------------------------------
> >> r24601 | dlr | 2007-04-16 18:50:29 -0500 (Mon, 16 Apr 2007) | 3 lines
> >> === result of merge in r24678 ===
> >>
> >> * notes/merge-tracking.txt
> >> Sign Kamesh up for the "all unmerged revisions" task, per his request.
> >
> > Yes, exactly. This is a divergence from what svnmerge.py does (IIRC,
> > Giovanni suggested it), in that there's no indentation of the
> > *original* log message(s), and that we aren't listing the *actual* log
> > message.
>
> I like this representation better. Is there a particular reason for
> omitting the *actual* log message?
I too prefer something like this representation to what svnmerge.py
does. Omitting the actual log message would be more consistent with
the behavior of 'blame', which will be showing the original revision
number in which a line was changed, rather than the actual revision
number. (While I personally kind of like the idea of showing both, I
think the additional output might be more noise than signal).
Re: Merge Tracking Auditing - SoC
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
Daniel Rall wrote:
> On Tue, 17 Apr 2007, Hyrum K. Wright wrote:
>
>> Daniel Rall wrote:
>>> On Tue, 17 Apr 2007, Hyrum K. Wright wrote:
>>>
>>>> Daniel Rall wrote:
>>>>> On Mon, 16 Apr 2007, Hyrum K. Wright wrote:
>>>> ...
>>>>>> * 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.
>>>> I'm having trouble parsing that last sentence. Would you mind restating it?
>>> If we decide not to show the *actual* log message used with a commit
>>> (which would be consistent with what we're going to do for 'blame'),
>>> some indication in the output of the *original* log message(s) that
>>> they aren't the actual log message, and are being displayed in lieu of
>>> the actual message, might be useful.
>> So, basically something to the effect of: (the revision numbers below
>> are somewhat bogus.)
>>
>> ------------------------------------------------------------------------
>> r24602 | dlr | 2007-04-16 19:02:48 -0500 (Mon, 16 Apr 2007) | 3 lines
>> === result of merge in r24678 ===
>>
>> * notes/merge-tracking.txt
>> Add issue #2769, and sign up for it.
>>
>> ------------------------------------------------------------------------
>> r24601 | dlr | 2007-04-16 18:50:29 -0500 (Mon, 16 Apr 2007) | 3 lines
>> === result of merge in r24678 ===
>>
>> * notes/merge-tracking.txt
>> Sign Kamesh up for the "all unmerged revisions" task, per his request.
>
> Yes, exactly. This is a divergence from what svnmerge.py does (IIRC,
> Giovanni suggested it), in that there's no indentation of the
> *original* log message(s), and that we aren't listing the *actual* log
> message.
I like this representation better. Is there a particular reason for
omitting the *actual* log message?
-Hyrum
Re: Merge Tracking Auditing - SoC
Posted by Daniel Rall <dl...@collab.net>.
On Tue, 17 Apr 2007, Hyrum K. Wright wrote:
> Daniel Rall wrote:
> > On Tue, 17 Apr 2007, Hyrum K. Wright wrote:
> >
> >> Daniel Rall wrote:
> >>> On Mon, 16 Apr 2007, Hyrum K. Wright wrote:
> >> ...
> >>>> * 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.
> >> I'm having trouble parsing that last sentence. Would you mind restating it?
> >
> > If we decide not to show the *actual* log message used with a commit
> > (which would be consistent with what we're going to do for 'blame'),
> > some indication in the output of the *original* log message(s) that
> > they aren't the actual log message, and are being displayed in lieu of
> > the actual message, might be useful.
>
> So, basically something to the effect of: (the revision numbers below
> are somewhat bogus.)
>
> ------------------------------------------------------------------------
> r24602 | dlr | 2007-04-16 19:02:48 -0500 (Mon, 16 Apr 2007) | 3 lines
> === result of merge in r24678 ===
>
> * notes/merge-tracking.txt
> Add issue #2769, and sign up for it.
>
> ------------------------------------------------------------------------
> r24601 | dlr | 2007-04-16 18:50:29 -0500 (Mon, 16 Apr 2007) | 3 lines
> === result of merge in r24678 ===
>
> * notes/merge-tracking.txt
> Sign Kamesh up for the "all unmerged revisions" task, per his request.
Yes, exactly. This is a divergence from what svnmerge.py does (IIRC,
Giovanni suggested it), in that there's no indentation of the
*original* log message(s), and that we aren't listing the *actual* log
message.
Re: Merge Tracking Auditing - SoC
Posted by Stefan Küng <to...@gmail.com>.
On 4/18/07, Daniel Rall <dl...@collab.net> wrote:
> On Tue, 17 Apr 2007, Stefan Küng wrote:
>
> > Hyrum K. Wright wrote:
> ...
> > >So, basically something to the effect of: (the revision numbers below
> > >are somewhat bogus.)
> > >
> > >------------------------------------------------------------------------
> > >r24602 | dlr | 2007-04-16 19:02:48 -0500 (Mon, 16 Apr 2007) | 3 lines
> > >=== result of merge in r24678 ===
> > >
> > >* notes/merge-tracking.txt
> > > Add issue #2769, and sign up for it.
> > >
> > >------------------------------------------------------------------------
> > >r24601 | dlr | 2007-04-16 18:50:29 -0500 (Mon, 16 Apr 2007) | 3 lines
> > >=== result of merge in r24678 ===
> > >
> > >* notes/merge-tracking.txt
> > > Sign Kamesh up for the "all unmerged revisions" task, per his request.
> >
> > I like that idea. But for me, how the log message output looks is not
> > that important. For me, it's more important how that data is passed in
> > the API. I suggest something like a map of revisions which got merged.
>
> Stefan, I've been assuming that we'd use a "mergeinfo" structure.
> That is, an apr_hash_t * of const char *path -> an apr_array_header_t *
> containing svn_merge_range_t *'s. Does this sound good to you?
> Alternately, we could pass in the textual representation of the merge
> info.
The mergeinfo structure would be great! No need for a textual
representation, I just would have to parse those which shouldn't be
necessary if the mergeinfo structure contains the information.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merge Tracking Auditing - SoC
Posted by Daniel Rall <dl...@collab.net>.
On Tue, 17 Apr 2007, Stefan Küng wrote:
> Hyrum K. Wright wrote:
...
> >So, basically something to the effect of: (the revision numbers below
> >are somewhat bogus.)
> >
> >------------------------------------------------------------------------
> >r24602 | dlr | 2007-04-16 19:02:48 -0500 (Mon, 16 Apr 2007) | 3 lines
> >=== result of merge in r24678 ===
> >
> >* notes/merge-tracking.txt
> > Add issue #2769, and sign up for it.
> >
> >------------------------------------------------------------------------
> >r24601 | dlr | 2007-04-16 18:50:29 -0500 (Mon, 16 Apr 2007) | 3 lines
> >=== result of merge in r24678 ===
> >
> >* notes/merge-tracking.txt
> > Sign Kamesh up for the "all unmerged revisions" task, per his request.
>
> I like that idea. But for me, how the log message output looks is not
> that important. For me, it's more important how that data is passed in
> the API. I suggest something like a map of revisions which got merged.
Stefan, I've been assuming that we'd use a "mergeinfo" structure.
That is, an apr_hash_t * of const char *path -> an apr_array_header_t *
containing svn_merge_range_t *'s. Does this sound good to you?
Alternately, we could pass in the textual representation of the merge
info.
Re: Merge Tracking Auditing - SoC
Posted by Stefan Küng <to...@gmail.com>.
Hyrum K. Wright wrote:
> Daniel Rall wrote:
>> On Tue, 17 Apr 2007, Hyrum K. Wright wrote:
>>
>>> Daniel Rall wrote:
>>>> On Mon, 16 Apr 2007, Hyrum K. Wright wrote:
>>> ...
>>>>> * 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.
>>> I'm having trouble parsing that last sentence. Would you mind restating it?
>> If we decide not to show the *actual* log message used with a commit
>> (which would be consistent with what we're going to do for 'blame'),
>> some indication in the output of the *original* log message(s) that
>> they aren't the actual log message, and are being displayed in lieu of
>> the actual message, might be useful.
>
> So, basically something to the effect of: (the revision numbers below
> are somewhat bogus.)
>
> ------------------------------------------------------------------------
> r24602 | dlr | 2007-04-16 19:02:48 -0500 (Mon, 16 Apr 2007) | 3 lines
> === result of merge in r24678 ===
>
> * notes/merge-tracking.txt
> Add issue #2769, and sign up for it.
>
> ------------------------------------------------------------------------
> r24601 | dlr | 2007-04-16 18:50:29 -0500 (Mon, 16 Apr 2007) | 3 lines
> === result of merge in r24678 ===
>
> * notes/merge-tracking.txt
> Sign Kamesh up for the "all unmerged revisions" task, per his request.
I like that idea. But for me, how the log message output looks is not
that important. For me, it's more important how that data is passed in
the API. I suggest something like a map of revisions which got merged.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Merge Tracking Auditing - SoC
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
Daniel Rall wrote:
> On Tue, 17 Apr 2007, Hyrum K. Wright wrote:
>
>> Daniel Rall wrote:
>>> On Mon, 16 Apr 2007, Hyrum K. Wright wrote:
>> ...
>>>> * 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.
>> I'm having trouble parsing that last sentence. Would you mind restating it?
>
> If we decide not to show the *actual* log message used with a commit
> (which would be consistent with what we're going to do for 'blame'),
> some indication in the output of the *original* log message(s) that
> they aren't the actual log message, and are being displayed in lieu of
> the actual message, might be useful.
So, basically something to the effect of: (the revision numbers below
are somewhat bogus.)
------------------------------------------------------------------------
r24602 | dlr | 2007-04-16 19:02:48 -0500 (Mon, 16 Apr 2007) | 3 lines
=== result of merge in r24678 ===
* notes/merge-tracking.txt
Add issue #2769, and sign up for it.
------------------------------------------------------------------------
r24601 | dlr | 2007-04-16 18:50:29 -0500 (Mon, 16 Apr 2007) | 3 lines
=== result of merge in r24678 ===
* notes/merge-tracking.txt
Sign Kamesh up for the "all unmerged revisions" task, per his request.
-Hyrum
Re: Merge Tracking Auditing - SoC
Posted by Daniel Rall <dl...@collab.net>.
On Tue, 17 Apr 2007, Hyrum K. Wright wrote:
> Daniel Rall wrote:
> > On Mon, 16 Apr 2007, Hyrum K. Wright wrote:
> ...
> >> * 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.
>
> I'm having trouble parsing that last sentence. Would you mind restating it?
If we decide not to show the *actual* log message used with a commit
(which would be consistent with what we're going to do for 'blame'),
some indication in the output of the *original* log message(s) that
they aren't the actual log message, and are being displayed in lieu of
the actual message, might be useful.
Re: Merge Tracking Auditing - SoC
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
Daniel Rall wrote:
> On Mon, 16 Apr 2007, Hyrum K. Wright wrote:
...
>> * 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.
I'm having trouble parsing that last sentence. Would you mind restating it?
Thanks,
-Hyrum
Re: Merge Tracking Auditing - SoC
Posted by Daniel Rall <dl...@collab.net>.
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?