kfogel@collab.net wrote:
> Olleg Samoylov <olleg@mipt.ru> writes:
>>I'll explain. Log message in version 1.x may have (in case of text
>>editor) or may have not (in case of "svn ci -m") trailing newline. And
>>this is not issue of text editor, trailing newline is appeared after
>>removing "--This line, and those below, will be ignored--", this issue
>>is entirely of subversion.
>
> Well, that depends how you define "line". If you define it to mean a
> bunch of non-newline characters followed by a newline (as I was
> proposing for a solution, in fact), then Subversion is doing exactly
> what it promises to do.
Where? In case "svn ci -m " or in case "svn ci"? :) In one case
subversion is not doing exactly what it promises to do, isn't it? :)
>>After patch "svn log" will check for trailing newline in log message
>>and only when it's needed add newline and increment "lines".
>
> So, my original objection to this patch was that it fixes the problem
> by misrepresenting the data (in a trival way, I admit). Right now,
> Subversion *always* adds a newline when displaying the log message, so
> you can always know exactly what the person actually entered for the
> log message. After this patch, that data is no longer recoverable.
Key words is "what the person actually entered for the log message"!
Trailing newline must be shown only when person actually enter it! (When
person press "enter" at the end of log message).
kfogel@collab.net wrote:
> Olleg Samoylov <olleg@mipt.ru> writes:
> 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.
It's not so easy. :)
When you type one line text string in text editor you don't press
"enter" at the end, isn't it? When you want add one text string more,
you former press "enter" (insert newline) and latter add text, isn't 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).
I do not mungle log data. I show it as is. But if log data haven't
trailing newline some bad things happens, output is jammed and count of
lines =0. This is bad, so I increment count of lines and add newline to
the end. This is all what doing my patch.
> The server-side solution has the advantage of solving the problem for
> all clients. I think I'd be +1 on your patch, as a compatibility
> measure for older repositories, *if* we also implemented this behavior
> on the server side. But doing only the client change seems wrong: log
> messages are repository data, they should be in the correct format
> when they are stored/retrieved in the repository.
Well, but client may work with old servers thus client must be patched too.
I am not developer of subversion, only user. No matter for me how you
keep my log messages. I what to see exactly what I type.
Force trailing newline is good, besause compatible with most text
editors, not only you like it. :) But I don't know subversion enough to
fix it on server side.
--
Olleg Samoylov
Received on Wed Mar 1 13:28:00 2006