kfogel@collab.net wrote:
> THE SPACING CAVEAT:
> -------------------
>
> Some also find the current waste of vertical space annoying: since
> most log messages already end with a newline, adding an unconditional
> extra newline (as we do today) causes a blank line before the
> separator in most cases. However, other people find the logs much
> easier to read with that blank line. Thus it might be that, after
> making all the changes described below, the command-line client should
> *still* print an extra blank line.
>
> THE HOOK ALTERNATIVE:
> ---------------------
IMHO much better after fixing bug write hook to add one newline more to
simulate old buggy behavior, if someone like it.
> In the command-line client, we would:
>
> a) When printing out a log message, no longer unconditionally print
> an extra newline in 'svn log' output to ensure that the log
> message body doesn't scrunch up against the following separator
> line. Instead, as a compatibility measure, check to see if the
> message already ends with a single newline; if it does, print
> nothing extra, otherwise, print a single extra newline and
> adjust the header's line count appropriately. (*** But see
> "Spacing" below ***).
My path do only this.
Enforce new format for log messages is cool, but:
1. This is not topic of my patch. (offtopic :) )
2. Do not anyone agree with it.
I agree to strictly define format of log messages (and other text
properties) someday, but I insist on my patch only. Because it is part
of the great Karl Fogel plan and :
Current format of text properties is not strict. Newline may or may not
be at the end. Clients is not enforced always place newline at the end
and is not enforced to remove it if user didn't type it manualy. Server
do not enforce trailing newline on input or output log messages. This is
current reality and some developers don't want change it.
O'key. Let see behavior of "svn log" in current reality. It's commonly
buggy. Most user don't type "enter" at the end of log message, but they
see blank line at the end in svn log later, because "svn log" always
expect log message without trailing newline. With current none strict
format of log messages this behavior is buggy.
What will be after the patch. "svn log" will show the same log message,
as user type it in most cases. I see only one exclusion, when behavior
will be wrong after the patch. Imagine someone want to place blank line
at the end. And do it like:
svn ci -m "want blank line at the end
"
Blank line will disappeare in log output, it's wrong but case is very
unusual. But if someone place blankline in text editor at the end, svn
log will show it as is.
Lets compare subversion before and after my patch. Before and after my
patch subversion do wrong sometimes. But before my patch subversion do
wrong as usual. After my patch in very unusual and artificial cases.
After my patch subversion will be better. It is good reason, isn't it?
And if you will enforce strict format of text properties in very far
future (in version 2.x), my patch will be compatible.
--
Olleg Samoylov
Received on Thu Mar 2 11:06:20 2006