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

Re: [PROPOSAL] enforce log messages as series of lines

From: Michael Brouwer <mb.7766_at_gmail.com>
Date: 2006-03-07 23:50:18 CET

(Resending this since I acidentally forgot to CC the list)

The only reason I'd suggest keeping the last newline rather than
removing it is that some editors (like the default vi on most systems)
always turn the last line into a newline, so if you did a propedit on
the log message of a revprop a newline would get appended. Of course
if you made sure that even after a propedit that newline was removed,
that would work as well.

Michael

On 3/6/06, Molle Bestefich <molle.bestefich@gmail.com> wrote:
> kfogel@collab.net wrote:
> > THE PROPOSAL:
> > -------------
> >
> > Subversion should enforce that a log message is a series of lines of
> > UTF8 text. A "line" is a series of zero or more non-newline
> > characters (qualified by whatever other restrictions we currently put
> > on log messages), followed by a single newline. Thus, every log
> > message would end with a single newline.
>
> I think TSVN already does something like this?
>
> I think it strips all preceding and terminating newlines in log messages.
>
> (Seemed odd to me at first since I would personally have liked to
> preserve a terminating newline. Anyway, got used to it pretty quick,
> nice to see consistency enforced. And it probably saves a byte of
> storage per log message :-).)
>
> If I'm right, and TSVN strips the last newline also, perhaps it's
> worth doing the same (= NOT enforcing a trailing newline, but
> enforcing removing it) in the client libraries, just to keep log
> messages in "TSVN repositories" consistent when/if this new feature is
> introduced..
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
Received on Tue Mar 7 23:50:44 2006

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.