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

Re: [PATCH] truncate EDITOR_EOF_PREFIX with previous EOL

From: Michael W Thelen <mike_at_pietdepsi.com>
Date: 2005-07-22 20:06:04 CEST

C. Michael Pilato wrote:
>>As far as I can tell from this thread, the only real problem is in the
>>display produced by "svn log". When the log message ends in a
>>newline, svn log displays one more newline than expected. If that's
>>the problem, then I think the solution is to modify the svn log code
>>that displays log messages (solution #2 in Karl's original response to
>>this thread). Make it only add a newline if the log message doesn't
>>already end in one. Would that behavior completely solve this problem?
> It would solve some folks' complaints about seeing extra whitespace
> after their log messages, yes. But it creates another more serious
> problem -- data tainting. Right now, you can write a parser for 'svn
> log' which can correctly reconstruct the original log message using
> these simple rules:
> 1. Always read the number of log lines dictated in the log header.
> 2. Always remove one (1) trailing EOL from that log message.
> If the output code becomes conditional, there's no post-facto way to
> tell whether or not the condition was triggered.

That is true. If svn log output is mostly for pretty display and
happens to be machine-parseable, then this may not be such a big issue
since you can use "svn log --xml" for the exact log message. It can be
argued that anyone who wants the exact log message should use --xml.
The trade-off may work in favor of nice display over exact accuracy.

But if svn log output is intended to allow exact reconstruction of the
original log message, including ending newlines, then you are right. In
that case, I think the solution is to leave the behavior as it is. This
argument also applies when svn log output is available, but "svn log
--xml" cannot be called, such as when the output has been saved to a
file and taken offline.

So the question becomes: is svn log output intended for nice display, or
is it intended to allow exact reconstruction of the log message? Can
the exactness constraint be relaxed given the existence of "svn log
--xml"? I don't know the answer to those questions, but I think they're
the right questions.

Michael W Thelen
It is a mistake to think you can solve any major problems just with
potatoes.       -- Douglas Adams
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 22 20:06:55 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.