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

Re: [Issue 2367] get rid of "... | N lines" slot in log message header

From: Christopher Ness <chris_at_nesser.org>
Date: 2005-07-20 19:55:19 CEST

On Wed, 2005-07-20 at 11:08 -0500, kfogel@collab.net wrote:
> In http://subversion.tigris.org/issues/show_bug.cgi?id=2367 I
> suggested the following as a 2.0 change:
>
> > Currently 'svn log' output shows the number of lines in the log message:
> >
> > r1729 | jrandom | 2005-07-31 21:12:50 -0500 (Sun, 31 Jul 2005) | 4 lines
> >
> > The idea was to make log messages unambiguously delimited. Someone
> > could even write the default log message separator into their log
> > message and we could still parse 'svn log' output reliably.
> >
> > In practice, no one ever seems to put the log message separator (a
> > line of 72 dashes) into their log messages. Maybe there are cases
> > in the wild I'm unaware of. Meanwhile, people sometimes
> > misinterpret the "N lines" as meaning "N lines were changed in this
> > commit". Oops. If we got rid of that field, we'd have room for
> > other information -- longer usernames, if nothing else. Or we could
> > say "N files" instead, a nice summary of the approximate size of the
> > commit. I dunno, let your imagination run wild.

What about removing the term "lines". Just have a number after the |
separator. Then users will not generate that misconception.

I'm sure there are a few scripts written in the wild that will break if
you remove that field entirely.

Cheers,
Chris

-- 
Wireless Group
McMaster University
summer
13:52:06 up 7 days, 4:42, 2 users, load average: 0.28, 0.26, 0.21
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 20 19:55:57 2005

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.