You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Adrian Robert <ar...@cogsci.ucsd.edu> on 2004/02/09 17:31:00 UTC

svn log lines (was Re: How does log translate to diff)

> From: kfogel@collab.net <kf...@collab.net>
> Date: 02 Sep 2003 13:59:44 -0500
> Content-Type: text/plain; charset=us-ascii
> Subject: How does log translate to diff
>
>
> Jack Repenning <jr...@collab.net> writes:
> > >I'd interpret this to mean that one line changed between these two
> > >revisions.
> >
> > I think the "1 line" thing is just bogus.  I always seem to get that
> > claim, no matter how much change has occurred.
>
> It gives the number of lines in the log message, not the number of
> lines in the change.  (It's to help auto-parsing of the log message.)

Does anyone here actually think it is more important to inform 
auto-parsers of the number of lines in the log message (which could 
surely be determined anyway by just counting newline characters or 
whatever, and for that matter autoparser tools probably just reformat 
the log entry themselves) than to inform human readers of how many 
lines were changed?

However, note that, in fact, it CANNOT be lines changed, since the log 
entries are for _changesets_, not indidivual files.  However the other 
surface parallels to CVS log messages make this very confusing to CVS 
users -- most probably assume the tool is just broken ("the 1 lines is 
bogus" as people have been saying).

I therefore suggest removing the "XX lines" info completely (not really 
useful, and confusing to new adopters, particularly since it doesn't 
seem to be documented anywhere), and adding the traditional CVS "+x-y" 
info to the "svn log -v" output (put it next to each item under 
"Changed paths:".  This +/- info really is very useful -- it tells at a 
glance "how much change" occurred in the file, AND whether the code 
grew larger or smaller in the change (a very useful piece of 
information for developers).

Anyone agree or disagree?


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: svn log lines (was Re: How does log translate to diff)

Posted by "C. Michael Pilato" <cm...@collab.net>.
Adrian Robert <ar...@cogsci.ucsd.edu> writes:

> Probably it will be useful to wait for more feedback, but do you see
> anything wrong with the points that:
> 
> 1) having the "X lines" in the log output is confusing for ex-CVS
> users due to the mis-parallel with CVS logs
> 
> 2) it would be nice to have the "+/- lines" added to 'svn log -v'

This could be done by sharing code with 'svn blame', which
interestingly enough does 'svn log' under the hood, then performs
contextual diffs on each successive version of the file.  Of course,
this information means nothing for 'svn log' on a directory (so you'd
have inconsistency in the output formats), and also for multiple
targets, we intermingle their log reports and try to avoid duplicating
revision logs common to more than one target.  This presents yet
another display problem, because now you can have more than one +/-
calculation per displayed log section.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: svn log lines (was Re: How does log translate to diff)

Posted by kf...@collab.net.
Adrian Robert <ar...@cogsci.ucsd.edu> writes:
> Probably it will be useful to wait for more feedback, but do you see
> anything wrong with the points that:
> 
> 1) having the "X lines" in the log output is confusing for ex-CVS
> users due to the mis-parallel with CVS logs

There's no right answer here.  Point (1) is valid, but so is the point
that adding Yet Another Option is not great either.

I don't feel strongly enough about it to change anything, and do feel
it's better not to change the interface once established.  But I'm
only -0, not -1.  If you persuade the other committers, I won't stand
in the way.

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: svn log lines (was Re: How does log translate to diff)

Posted by Adrian Robert <ar...@cogsci.ucsd.edu>.
Probably it will be useful to wait for more feedback, but do you see 
anything wrong with the points that:

1) having the "X lines" in the log output is confusing for ex-CVS users 
due to the mis-parallel with CVS logs

2) it would be nice to have the "+/- lines" added to 'svn log -v'

If not, should I submit enhancement requests on the bugzilla?  I can 
understand that adding (2) might be hard if that info is not readily 
available within subversion, but addressing (1) by putting the lines in 
only under an option to svn log that parsers can use seems easy...

best,
Adrian



On Feb 9, 2004, at 4:10 PM, kfogel@collab.net wrote:

> Yes, the line count was added for guaranteed parseability, in case a
> log message by chance included the separator line.
>
> Holger Krekel <py...@devel.trillke.net> writes:
>> hmmm, i wonder if parsers shouldn't just go for the much more
>> machine-readable xml-format, anyway.
>
> Some parsers do, some don't.  (The ones I write usually don't use the
> XML format.)
>
>> Btw, a friend and me have written a higher level python abstraction
>> for svn-stuff and it's mostly a pain to parse 'svn' output apart from
>> 'svn log --xml'.
>
> Now that's just FUD :-).  I've written such parsers multiple times in
> different languages, using the line count, and it was very easy.
>
> -Karl
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: svn log lines (was Re: How does log translate to diff)

Posted by kf...@collab.net.
Yes, the line count was added for guaranteed parseability, in case a
log message by chance included the separator line.

Holger Krekel <py...@devel.trillke.net> writes:
> hmmm, i wonder if parsers shouldn't just go for the much more 
> machine-readable xml-format, anyway.   

Some parsers do, some don't.  (The ones I write usually don't use the
XML format.)

> Btw, a friend and me have written a higher level python abstraction 
> for svn-stuff and it's mostly a pain to parse 'svn' output apart from 
> 'svn log --xml'.  

Now that's just FUD :-).  I've written such parsers multiple times in
different languages, using the line count, and it was very easy.

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: svn log lines (was Re: How does log translate to diff)

Posted by Holger Krekel <py...@devel.trillke.net>.
Adrian Robert wrote:
> 
> On Feb 9, 2004, at 12:38 PM, Florian Weimer wrote:
> 
> >Adrian Robert wrote:
> >
> >>Does anyone here actually think it is more important to inform
> >>auto-parsers of the number of lines in the log message (which could
> >>surely be determined anyway by just counting newline characters or
> >>whatever,
> >
> >The line count is important if you want to parse a stream of log
> >messages, and message separators occuring in log messages aren't 
> >escaped
> >in some way.  CVS has this problem and that's the reason for presenting
> >the line count in Subversion, I guess.  At least I immediately thought
> >"ah, good idea" when I saw these line numbers for the first time. 8-)
> 
> Good point, though it seems like a bit overengineering for corner cases 
> (if 79 contiguous dashes was a string thought likely to occur in log 
> messages, perhaps a more clever delimiter, throw in an additional 
> character of some sort, for example, might have worked).  Still, given 
> the state now maybe the best solution would be to add an option to svn 
> log, say "-m [include additional annotation for automated parsing]", 
> and to _leave out_ the "X lines" message by default -- it's just noise 
> to human readers.

hmmm, i wonder if parsers shouldn't just go for the much more 
machine-readable xml-format, anyway.   

Apart from that, i agree that removing the count of 
loglines makes sense in the default 'svn log' case. 

Btw, a friend and me have written a higher level python abstraction 
for svn-stuff and it's mostly a pain to parse 'svn' output apart from 
'svn log --xml'.  (And no, i don't want to require the presence of
bindings because that cuts out 95% of them). 

    holger

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: svn log lines (was Re: How does log translate to diff)

Posted by Adrian Robert <ar...@cogsci.ucsd.edu>.
On Feb 9, 2004, at 12:38 PM, Florian Weimer wrote:

> Adrian Robert wrote:
>
>> Does anyone here actually think it is more important to inform
>> auto-parsers of the number of lines in the log message (which could
>> surely be determined anyway by just counting newline characters or
>> whatever,
>
> The line count is important if you want to parse a stream of log
> messages, and message separators occuring in log messages aren't 
> escaped
> in some way.  CVS has this problem and that's the reason for presenting
> the line count in Subversion, I guess.  At least I immediately thought
> "ah, good idea" when I saw these line numbers for the first time. 8-)

Good point, though it seems like a bit overengineering for corner cases 
(if 79 contiguous dashes was a string thought likely to occur in log 
messages, perhaps a more clever delimiter, throw in an additional 
character of some sort, for example, might have worked).  Still, given 
the state now maybe the best solution would be to add an option to svn 
log, say "-m [include additional annotation for automated parsing]", 
and to _leave out_ the "X lines" message by default -- it's just noise 
to human readers.

I'm not bashing the designers/implementers at all, this is something 
that only shows up through hindsight...  And although many people might 
understand right away what the "X lines" means (and subsequently tune 
it out), given that many users will be coming from CVS (see example log 
message below), it seems worthwhile getting rid of it in the default 
case.

CVS:
----------------------------
revision 1.2
date: 2003/04/10 19:51:00;  author: arobert;  state: Exp;  lines: +14 -4
updated for recent changes
----------------------------

SVN:
------------------------------------------------------------------------
r368 | arobert | 2004-02-09 11:58:57 -0500 (Mon, 09 Feb 2004) | 1 line

testing
------------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: svn log lines (was Re: How does log translate to diff)

Posted by Florian Weimer <fw...@deneb.enyo.de>.
Adrian Robert wrote:

> Does anyone here actually think it is more important to inform 
> auto-parsers of the number of lines in the log message (which could 
> surely be determined anyway by just counting newline characters or 
> whatever, 

The line count is important if you want to parse a stream of log
messages, and message separators occuring in log messages aren't escaped
in some way.  CVS has this problem and that's the reason for presenting
the line count in Subversion, I guess.  At least I immediately thought
"ah, good idea" when I saw these line numbers for the first time. 8-)

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org