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

Re: patch newline in log messages

From: <kfogel_at_collab.net>
Date: 2006-02-28 23:52:00 CET

Olleg Samoylov <olleg@mipt.ru> writes:
> Philip Martin wrote:
> > The two log messages "foo" and "foo\n" currently show up as different
> > because they are different. Why is that bad? Why should Subversion
> > hide the difference? If hiding the difference really is the right
> > thing to do then what about: "foo\n\n", "\n\nfoo\n\n", "foo \n",
> > should they be made to look the same as well?
>
> Because user don't enter newline. User enter the same message with
> "svn ci -m" and with "svn ci" and text editor. Subversion in case of
> text editor add '\n' at the end of log message, in case of "svn ci -m"
> not.

With the text editor, the user left the newline, though probably
unintentionally. The user *could* have removed that newline, but most
users do not.

I do not consider the preceding newline to be part of the special
"--Text...will be removed--" line, but rather the end of the line
before. There are good reasons for this: all users seeing a file like
"\nsometext" or "\nsometext\n" will consider it to have at least two
lines. Many people would consider both "sometext" and "sometext\n" to
be one line long. To me, this all means that a newline is clearly
part of the line before it, not the line after it.

Not that any of this matters. If we agree that log messages should be
a series of lines, where each line ends with a newline, then we should
enforce that. If we do not agree, then we must not munge log data at
all (i.e., we must ensure that the original log is recoverable, which
the current behavior does).

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 1 01:38:28 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.