You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Olleg Samoylov <ol...@mipt.ru> on 2005/07/19 11:18:15 UTC
[PATCH] truncate EDITOR_EOF_PREFIX with previous EOL
In log message wroten by editor always added trailing eol. This patch remove it.
--
Olleg Samoylov
[[[
* subversion/clients/cmdline/util.c
(truncate_buffer_at_prefix): Remove trailing eol from log message.
]]]
Index: subversion/clients/cmdline/util.c
===================================================================
--- subversion/clients/cmdline/util.c (revision 15361)
+++ subversion/clients/cmdline/util.c (working copy)
@@ -417,6 +417,14 @@
|| (*(substring - 1) == '\r')
|| (*(substring - 1) == '\n'))
{
+ /* Remove previous eol. */
+ while (substring != buffer)
+ if ((*(substring - 1) == '\r')
+ || (*(substring - 1) == '\n'))
+ substring--;
+ else
+ break;
+
*substring = '\0';
if (new_len)
*new_len = substring - buffer;
Re: [PATCH] truncate EDITOR_EOF_PREFIX with previous EOL
Posted by Olleg Samoylov <ol...@mipt.ru>.
kfogel@collab.net wrote:
> (Unless some new argument appears, this will be my last response in
> this thread.)
I already lost hope. But I try. :-)
Argument simple. There are different methods to write a same message
("test" for instance). "svn commit --message" or "svn commit" (with
editor) for instance.
I expect, if I write message by different methods, result will be same.
Now it is not true. IMHO it's bug. You said - "feature".
Of cause I can fix problem without you. But I tried make subversion better.
--
Olleg Samoylov
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] truncate EDITOR_EOF_PREFIX with previous EOL
Posted by kf...@collab.net.
(Unless some new argument appears, this will be my last response in
this thread.)
Olleg Samoylov <ol...@mipt.ru> writes:
> I undestand why this happens. But your can't undestand one simple thing.
> One line message is always one line message. And every human can
> approve it. No matter how computer make wrong decision.
I don't understand this (but I don't think it's a language problem).
> > If you truly want one line, why not just remove everything but that
> > one line?
>
> As I already said, if a bug have a workaround it don't begin looked
> like a customizable feature.
>
> > I don't think the patch is an improvement, because it's not clear that
> > the current behavior is incorrect. Defaulting to having the newline
> > seems reasonable, at least as reasonable as not having it.
>
> Well, let me explain again. "svn log" don't expect EOL at the
> end. "svn commit --message", "svn commit --file" and "svn commit"
> (with editor) don't add EOL if it not exist. Almost code wroted as if
> log message have not trailing EOL.
This is irrelevant. Those modes take their log message data in final
form. The mode we are discussing takes the data in non-final form and
has to tweak it before committing. We are discussing the right way to
tweak it. If any other command also had to tweak it, then this
discussion would apply to that command too.
I don't understand why you characterize it as "adding" an eol. If the
log message looked like this:
Here is my multi-line log message.
This is the second line of my log message.
This is the third line of my log message.
This is the fourth line of my log message.
This is the fifth line of my log message.
--This line, and those below, will be ignored--
...would you expect the last line to keep its trailing newline? If
not, why not? Or if so, then why would the reasoning change when the
log message is one line instead of five?
> There is chose. Rewrite almost code to support log message with
> trailing EOL, as Greg like. Or fix bug. Or do nothing? What your
> prefer?
Do nothing. I think the current behavior is fine, and not a bug.
> IMHO, will be convenient remove all white spaces at the end, not only
> EOL. They arised by mistype usually. Don't have any useful
> information. And invisible for human to fix it manualy.
>
> Do you have argument to negate this?
Here is the same argument I made before, but expressed more clearly.
Assume that the log message in the editor says this:
here is my log message
--This line, and those below, will be ignored--
And now the user saves, exits, and thus finishes the commit, without
editing the log message any further. In this circumstance, some users
will want the newline after "message" preserved, and other users will
want it stripped. Subversion has no way to guess which way a
particular user wants. For example, I always want it preserved,
whereas you apparently always want it stripped.
Each of us can guarantee our desired outcome, by simply removing the
newline and the separator line, and anything below that. So the only
question is, what should Subversion do by default, if we *don't*
remove those things? I agree with Greg that most log messages are
meant to be treated as a series of lines, and that therefore a
reasonable default is to put a newline after the last line (yes, even
when the last line is also the first line). This is not enforcing
anything; it is *choosing* a good default when the user has expressed
no clear preference.
I don't really understand why you think this behavior is a bug, but as
you've tried to explain it several times now, I think I am unlikely to
ever understand.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] truncate EDITOR_EOF_PREFIX with previous EOL
Posted by kf...@collab.net.
Olleg Samoylov <ol...@mipt.ru> writes:
> I am surprised by policy of applying patches too. Is here something
> like "Debian Technical Committee"? Or all decisions maded by folks
> form collab.net?
The group of full committers makes final decisions. There are 45 full
committers, of whom 4 are CollabNet employees, so no, CollabNet does
not have the power to force decisions here :-).
See the COMMITTERS file.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] truncate EDITOR_EOF_PREFIX with previous EOL
Posted by Olleg Samoylov <ol...@mipt.ru>.
Julian Foad wrote:
> We can argue that making log messages end consistently would be better
> for us, but another Subversion user might want to retrieve the log
> message and feed it back into the editor that created it; if Subversion
> had altered the ending, that might give unpleasant results. So, there
> is no single behaviour that everyone can agree is the correct behaviour.
At current moment EOL at the end is not guarantied. It is only arised in
some cases. Nobody can expect EOL at the end always. And the "another
Subversion user" must keep it in mind.
>> There is chose. Rewrite almost code to support log message with
>> trailing EOL, as Greg like. Or fix bug. Or do nothing? What your prefer?
>
> ("There is a choice.")
Thank you. You undestand me even in a wrong phrase. :-)
> Unfortunately for you and me, I think in this situation the best thing
> is to do nothing at the moment. In version 2 of the Subversion
> command-line client, we could do something different. Other clients,
> such as TortoiseSVN, can do something different.
Yes, of cause. But. Now there are two variant of existance an one line
message. One of them wrong, isn't it? Why we can't fix it now?
>> IMHO, will be convenient remove all white spaces at the end, not only
>> EOL. They arised by mistype usually. Don't have any useful
>> information. And invisible for human to fix it manualy.
>
> Yes, I agree. I would like to use a client that removes all trailing
> white space (or replaces it with a single newline control code). I
> wrote my own patch last year to do this in a different way, and (IIRC)
> it also was rejected by the Subversion team. We will just have to get
> used to it, or use a patched or different client program to display the
> log messages.
Simplest way write hook script or use only "svn commit --message".
I am surprised by policy of applying patches too. Is here something like
"Debian Technical Committee"? Or all decisions maded by folks form
collab.net?
--
Olleg Samoylov
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] truncate EDITOR_EOF_PREFIX with previous EOL
Posted by Julian Foad <ju...@btopenworld.com>.
kfogel@collab.net wrote:
> Julian Foad <ju...@btopenworld.com> writes:
>
>>Olleg, I agree with you that the behaviour is odd and unpleasant and
>>seems to be wrong. I also would like the program to remove trailing
>>whitespace, either when creating or when displaying the log message.
>
> I am totally, completely opposed to Subversion taking the trailing
> newline off my log messages. Take my house, take my car, take my
> piano (well, no, leave the piano please) but DO NOT TAKE my trailing
> newline.
>
> Thank you :-).
That's fine - I don't want your trailing newline anyway, I'd much prefer your
piano. Hmm... That'll teach me not to respond in such imprecise terms to a
thread whose aims and arguments are already confused and whose contributors are
already misunderstanding each other.
Actually, I don't particularly want the final newline character to be removed.
What I meant was primarily that I really do not want the display from "svn
log" to have _extra_ visible whitespace (i.e. an extra blank line).
Secondarily, I wouldn't mind if all trailing spaces and/or blank lines were
removed when the "This line and below..." stuff is removed, although I can now
see and accept why you wouldn't want that; and I would also feel more
comfortable if the internal storage of the log messages would have consistent
line ending conventions (all messages ending with a newline character, or all
not doing so).
Removing any final newline character would make the log messages be consistent
with the log messages that are typically entered on the command line in a
quoted string argument to "-m", where the user doesn't generally add a literal
newline character before closing the string, but I generally consider a "line"
to be incomplete without its terminating newline control character. Thus I
might prefer to have "svn" add a newline character to any provided log message
if it is missing.
But these specific ideas for specific behaviours are, I think, pretty much moot
at this time. All I was trying to do was to show some understanding and
support for the original poster, because all other respondents seemed to be
shooting him down with statements and technical details that didn't closely
relate to the user experience.
>
>>>>Well, you didn't write one line :-). You wrote a line, followed by a
>>>> newline, followed by a line that promised its own removal at
>>>>commit time, along with everything following it. And that's
>>>>exactly what happens right now.
>>
>>(Well, Karl, that's unfair, and you know it!)
>
> Uh, no, I meant it seriously.
Sorry, I didn't mean to get your back up. Unfortunately I think your use of
the word "wrote" just fanned the flames.
> The user has left a message in the
> buffer that can be interpreted multiple ways, Subversion has to make a
> choice. [...]
That's the thing: he left extra stuff in the buffer that he didn't write. To
me it was obvious that Olleg was speaking as a user when he said he wrote one
line. The fact that the system (svn and the editor) conspired to add a newline
character and further lines of text to what he wrote, and feed the whole lot
back into svn, is an aspect of the technical operation that merely detracted
attention from what he actually wrote.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] truncate EDITOR_EOF_PREFIX with previous EOL
Posted by Greg Hudson <gh...@MIT.EDU>.
On Fri, 2005-07-22 at 23:49 +0400, Olleg Samoylov wrote:
> > * The svn:log property gives the log message, with the exception that
> > if svn:log does not end in a newline, then it is ever so slightly
> > corrupt.
> In this view "svn log" gives the exact log message except "slightly
> corrupted" (without newline).
No, you misread. In this view "svn log" gives the exact log message.
It is the svn:log property which (in this view) is slightly corrupt, and
needs to be adjusted in order to yield the exact log message.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] truncate EDITOR_EOF_PREFIX with previous EOL
Posted by Olleg Samoylov <ol...@mipt.ru>.
It's better, then nothing.
Greg Hudson wrote:
> There's another, admittedly more subtle way of looking at this:
>
> * The log message is a sequence of lines.
Okey, why not. Much more code will be rewriten. But you'll get your
favorite format of log messages.
May be other svn properties must be considered as a sequence of lines also?
> * The svn:log property gives the log message, with the exception that
> if svn:log does not end in a newline, then it is ever so slightly
> corrupt. In this case, "svn log" will correct for that (the log message
> becomes the svn:log property plus a newline) because historically, we
> haven't enforced that constraint.
As I can undestand at current moment "svn log" always add one newline.
New algorithm is better.
> * The client will ensure that svn:log values end in a newline when new
> revisions are committed and when "svn propset" is done. (Will the
> server also enforce this constraint? I'm not sure; how much enforcement
> do we do on other svn: properties?)
Server must enforce this constraint. Or other subversion client will
break it.
> Obviously, I am describing some hypothetical future Subversion, not the
> current one.
If format of log messages as "a sequence of lines" will be standart in
some hypothetical future then no reason guard it now.
>>So the question becomes: is svn log output intended for nice display,
>>or is it intended to allow exact reconstruction of the log message?
>
> In this view, "svn log" gives the exact log message, but not always the
> exact value of the svn:log property. For that you use svn propget
> --revprop --strict svn:log.
In this view "svn log" gives the exact log message except "slightly
corrupted" (without newline). Why do you want give method to get
"slightly corrupted" log messages?
--
Olleg Samoylov
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] truncate EDITOR_EOF_PREFIX with previous EOL
Posted by Greg Hudson <gh...@MIT.EDU>.
On Fri, 2005-07-22 at 12:06 -0600, Michael W Thelen wrote:
> But if svn log output is intended to allow exact reconstruction of the
> original log message, including ending newlines, then you are right.
There's another, admittedly more subtle way of looking at this:
* The log message is a sequence of lines.
* The svn:log property gives the log message, with the exception that
if svn:log does not end in a newline, then it is ever so slightly
corrupt. In this case, "svn log" will correct for that (the log message
becomes the svn:log property plus a newline) because historically, we
haven't enforced that constraint.
* The client will ensure that svn:log values end in a newline when new
revisions are committed and when "svn propset" is done. (Will the
server also enforce this constraint? I'm not sure; how much enforcement
do we do on other svn: properties?)
Obviously, I am describing some hypothetical future Subversion, not the
current one.
> So the question becomes: is svn log output intended for nice display,
> or is it intended to allow exact reconstruction of the log message?
In this view, "svn log" gives the exact log message, but not always the
exact value of the svn:log property. For that you use svn propget
--revprop --strict svn:log.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] truncate EDITOR_EOF_PREFIX with previous EOL
Posted by Julian Foad <ju...@btopenworld.com>.
C. Michael Pilato wrote:
> Michael W Thelen <mi...@pietdepsi.com> writes:
>
>>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.
>
> And I think the hints about the answers lie in a parallel thread going
> on right now regarding that "N lines" log header. The community
> appears to have rejected the removal of that bit of information on the
> grounds that doing so would make 'svn log' output less machine
> parsable. If machine parsability of data is a goal, I should think
> the accuracy of that data is pretty important.
No, your last thought is a non-sequitur: the reason for machine parsability in
this case is to allow the log message to be separated from the other log
details. There is no implicit assumption here that the extracted log message
needs to be identical to how it was originally provided, though such a
requirement might be expressed by some people.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] truncate EDITOR_EOF_PREFIX with previous EOL
Posted by "C. Michael Pilato" <cm...@collab.net>.
Michael W Thelen <mi...@pietdepsi.com> writes:
> 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.
And I think the hints about the answers lie in a parallel thread going
on right now regarding that "N lines" log header. The community
appears to have rejected the removal of that bit of information on the
grounds that doing so would make 'svn log' output less machine
parsable. If machine parsability of data is a goal, I should think
the accuracy of that data is pretty important.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] truncate EDITOR_EOF_PREFIX with previous EOL
Posted by Michael W Thelen <mi...@pietdepsi.com>.
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
Re: [PATCH] truncate EDITOR_EOF_PREFIX with previous EOL
Posted by "C. Michael Pilato" <cm...@collab.net>.
Michael W Thelen <mi...@pietdepsi.com> writes:
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] truncate EDITOR_EOF_PREFIX with previous EOL
Posted by Michael W Thelen <mi...@pietdepsi.com>.
kfogel@collab.net wrote:
> Julian Foad <ju...@btopenworld.com> writes:
>>Olleg, I agree with you that the behaviour is odd and unpleasant and
>>seems to be wrong. I also would like the program to remove trailing
>>whitespace, either when creating or when displaying the log message.
>
> I am totally, completely opposed to Subversion taking the trailing
> newline off my log messages. Take my house, take my car, take my
> piano (well, no, leave the piano please) but DO NOT TAKE my trailing
> newline.
>
> Thank you :-).
I agree with everything you've said in this message. If the user, via
her editor, has committed a log message with a trailing newline, her
wishes should be respected and the newline should be left alone.
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?
This solution has the advantage of leaving the log message alone, as the
user may have intended it. It will also fix the problem retroactively
for existing log messages that already end in newlines. Anyone with a
newer client would see existing log messages without extra newlines.
If the problem is in displaying log messages, let's fix it in the
display code. I don't believe this needs to wait for 2.0 either, since
we're not really changing the svn log display format. We'd simply be
displaying fewer lines than before, and the "X lines" information would
be updated appropriately.
--
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
Re: [PATCH] truncate EDITOR_EOF_PREFIX with previous EOL
Posted by kf...@collab.net.
Julian Foad <ju...@btopenworld.com> writes:
> Olleg, I agree with you that the behaviour is odd and unpleasant and
> seems to be wrong. I also would like the program to remove trailing
> whitespace, either when creating or when displaying the log message.
I am totally, completely opposed to Subversion taking the trailing
newline off my log messages. Take my house, take my car, take my
piano (well, no, leave the piano please) but DO NOT TAKE my trailing
newline.
Thank you :-).
> >> Well, you didn't write one line :-). You wrote a line, followed by a
> >> newline, followed by a line that promised its own removal at
> >> commit time, along with everything following it. And that's
> >> exactly what happens right now.
>
> (Well, Karl, that's unfair, and you know it!)
Uh, no, I meant it seriously. The user has left a message in the
buffer that can be interpreted multiple ways, Subversion has to make a
choice. But note that the actual *promise* being made by this:
--This line, and those below, will be ignored--
is merely that that line, and those below it, would be ignored. The
newline that ends the preceding line is not (usually, IMHO) considered
part of the next line, it is considered the last character of the
preceding line. So right now, we're keeping the promise. If we
remove that newline, we're doing more than we said we would. I'd call
*that* a bug, if anything.
> > IMHO, will be convenient remove all white spaces at the end, not
> > only EOL. They arised by mistype usually. Don't have any useful
> > information. And invisible for human to fix it manualy.
This assertion that they usually arise by mistype is unverifiable.
When I commit them, they are deliberate, and look over the Subversion
logs -- I almost always *do* commit them.
(By the way, this response doesn't violate my promise not to respond
again unless someone said something new. Julian did say something
new: he proposed to take away my grand piano! :-) )
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] truncate EDITOR_EOF_PREFIX with previous EOL
Posted by Julian Foad <ju...@btopenworld.com>.
Olleg Samoylov wrote:
> kfogel@collab.net wrote:
>
>> Olleg wrote:
>>
>>> I can't undestand official position of subversion developers.
>>> Obviously this is bug because svn don't work as expected. When I
>>> write 1 line message to log, I expect 1 line message in log. Clear
>>> and simple.
Olleg, I agree with you that the behaviour is odd and unpleasant and seems to
be wrong. I also would like the program to remove trailing whitespace, either
when creating or when displaying the log message.
Here is one fact that might make it seem less bad for you: When the Subversion
command-line client prints "2 lines" followed by your one-line log message and
then a blank line, the program is not lying by saying, "Your log message had
two lines," instead it is only saying, "I am going to use two lines to display
your log message." The number is put there only for other computer programs to
use; it is not really meant to be read by you.
>>
>> Well, you didn't write one line :-). You wrote a line, followed by a
>> newline, followed by a line that promised its own removal at commit
>> time, along with everything following it. And that's exactly what
>> happens right now.
(Well, Karl, that's unfair, and you know it!)
> I undestand why this happens. But your can't undestand one simple thing.
> One line message is always one line message. And every human can approve
> it. No matter how computer make wrong decision.
Yes, I agree, except that the computer has definite, valid reasons to use two
lines to display your one-line message. It's not exactly what you or I want,
but it was designed that way on purpose; it did not happen accidentally.
We can argue that making log messages end consistently would be better for us,
but another Subversion user might want to retrieve the log message and feed it
back into the editor that created it; if Subversion had altered the ending,
that might give unpleasant results. So, there is no single behaviour that
everyone can agree is the correct behaviour.
[...]
> There is chose. Rewrite almost code to support log message with trailing
> EOL, as Greg like. Or fix bug. Or do nothing? What your prefer?
("There is a choice.")
Unfortunately for you and me, I think in this situation the best thing is to do
nothing at the moment. In version 2 of the Subversion command-line client, we
could do something different. Other clients, such as TortoiseSVN, can do
something different.
>
> IMHO, will be convenient remove all white spaces at the end, not only
> EOL. They arised by mistype usually. Don't have any useful information.
> And invisible for human to fix it manualy.
Yes, I agree. I would like to use a client that removes all trailing white
space (or replaces it with a single newline control code). I wrote my own
patch last year to do this in a different way, and (IIRC) it also was rejected
by the Subversion team. We will just have to get used to it, or use a patched
or different client program to display the log messages.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] truncate EDITOR_EOF_PREFIX with previous EOL
Posted by Olleg Samoylov <ol...@mipt.ru>.
kfogel@collab.net wrote:
> Olleg wrote:
>
>> I can't undestand official position of subversion developers.
>> Obviously this is bug because svn don't work as expected. When I
>> write 1 line message to log, I expect 1 line message in log. Clear
>> and simple.
>
> Well, you didn't write one line :-). You wrote a line, followed by a
> newline, followed by a line that promised its own removal at commit
> time, along with everything following it. And that's exactly what
> happens right now.
I undestand why this happens. But your can't undestand one simple thing.
One line message is always one line message. And every human can approve
it. No matter how computer make wrong decision.
> If you truly want one line, why not just remove everything but that
> one line?
As I already said, if a bug have a workaround it don't begin looked like
a customizable feature.
> I don't think the patch is an improvement, because it's not clear that
> the current behavior is incorrect. Defaulting to having the newline
> seems reasonable, at least as reasonable as not having it.
Well, let me explain again. "svn log" don't expect EOL at the end. "svn
commit --message", "svn commit --file" and "svn commit" (with editor)
don't add EOL if it not exist. Almost code wroted as if log message have
not trailing EOL.
There is chose. Rewrite almost code to support log message with trailing
EOL, as Greg like. Or fix bug. Or do nothing? What your prefer?
IMHO, will be convenient remove all white spaces at the end, not only
EOL. They arised by mistype usually. Don't have any useful information.
And invisible for human to fix it manualy.
Do you have argument to negate this?
--
Olleg Samoylov
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] truncate EDITOR_EOF_PREFIX with previous EOL
Posted by kf...@collab.net.
Philip Martin <ph...@codematters.co.uk> writes:
> kfogel@collab.net writes:
> > At this point I've begun to suspect that two or more different
> > problems are being combined here, and would appreciate a concise bug
> > report that states exactly what is wrong with Subversion: what was the
> > expected behavior, and what was the actual behavior?
>
> Someone using the commit editor to create a commit message like
>
> one line
> --This line, and those below, will be ignored--
>
> _M .
>
> creates a raw log message "one line\n", the patch removes the trailing
> \n so that the raw log message is "one line".
Thank you for the summary. This much I garnered from the original
message, and summarized it as "Problem (3)" in this message:
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=102858
I somehow had gotten the feeling that the problem had drifted, from
subsequent messages in the thread. However, reading over them again
now, I don't think there was much drift, there were just a lot of
short but distracting tangents.
I don't think the patch is an improvement, because it's not clear that
the current behavior is incorrect. Defaulting to having the newline
seems reasonable, at least as reasonable as not having it. And the
workaround is simply to remove
"\n--This line, and those below, will be ignored--"
and everything after it manually. So right now, I think I agree with
Greg. If this patch fixes a bug for some people, it introduces a bug
for others.
Olleg wrote:
> I can't undestand official position of subversion
> developers. Obviously this is bug because svn don't work as
> expected. When I write 1 line message to log, I expect 1 line message
> in log. Clear and simple.
Well, you didn't write one line :-). You wrote a line, followed by a
newline, followed by a line that promised its own removal at commit
time, along with everything following it. And that's exactly what
happens right now. If you truly want one line, why not just remove
everything but that one line?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] truncate EDITOR_EOF_PREFIX with previous EOL
Posted by Philip Martin <ph...@codematters.co.uk>.
kfogel@collab.net writes:
> At this point I've begun to suspect that two or more different
> problems are being combined here, and would appreciate a concise bug
> report that states exactly what is wrong with Subversion: what was the
> expected behavior, and what was the actual behavior?
Someone using the commit editor to create a commit message like
one line
--This line, and those below, will be ignored--
_M .
creates a raw log message "one line\n", the patch removes the trailing
\n so that the raw log message is "one line".
Without the patch "svn log" displays something like
------------------------------------------------------------------------
r2 | pm | 2005-07-22 01:12:09 +0100 (Fri, 22 Jul 2005) | 2 lines
one line
------------------------------------------------------------------------
with the patch it would be
------------------------------------------------------------------------
r2 | pm | 2005-07-22 01:12:09 +0100 (Fri, 22 Jul 2005) | 1 line
one line
------------------------------------------------------------------------
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] truncate EDITOR_EOF_PREFIX with previous EOL
Posted by kf...@collab.net.
Olleg Samoylov <ol...@mipt.ru> writes:
> kfogel@collab.net wrote:
> > For Subversion's repository, how hard would it be to write a
> > pre-commit script that takes the log msg from the txn, removes all
> > leading and trailing blank lines and guarantees that the log message
> > ends with a single newline, and writes it back to the txn before the
> > commit? About fifteen minutes? Thirty? :-)
>
> How hard apply a patch? About two minutes? One?
You're missing the point, though.
We can put anything we want into our pre-commit script -- that affects
only us, not other projects. We can make any project policy we want
for ourselves. But making such decisions for *other* projects (i.e.,
by putting a patch into Subversion itself) is different, and must be
approached with much more care.
> I can't undestand official position of subversion
> developers. Obviously this is bug because svn don't work as
> expected. When I write 1 line message to log, I expect 1 line message
> in log. Clear and simple.
>
> They are several patches to fix. Ones fix "svn commit", others "svn
> log". Based on two opinion must or not log messages always ended with
> EOL.
>
> But all patches rejected and I advised to write hook script to fix this.
> I can't undestand. Can anyone explain me?
I wasn't advising you to write a pre-commit script. I was asking the
other developers here if they wanted this pre-commit script in
Subversion's *own* repository. You inspired my proposal, but my
proposal was not directed at you.
As for the "official position" of the svn developers, it is often the
case that there is no official position, and that we try to figure out
the best thing to do by discussing matters. That's what's happening
here.
At this point I've begun to suspect that two or more different
problems are being combined here, and would appreciate a concise bug
report that states exactly what is wrong with Subversion: what was the
expected behavior, and what was the actual behavior?
Thanks,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] truncate EDITOR_EOF_PREFIX with previous EOL
Posted by Olleg Samoylov <ol...@mipt.ru>.
> Greg Hudson <gh...@MIT.EDU> writes:
>>in the ideal case, svn:log properties should be thought of as a series
>>of lines, and we should ensure that they are by requiring that they have
>>a final newline.
Is this standart of log messages? "svn commit --message" and "svn log"
don't support this. And svn or server don't guarantee this invariant.
kfogel@collab.net wrote:
> For Subversion's repository, how hard would it be to write a
> pre-commit script that takes the log msg from the txn, removes all
> leading and trailing blank lines and guarantees that the log message
> ends with a single newline, and writes it back to the txn before the
> commit? About fifteen minutes? Thirty? :-)
How hard apply a patch? About two minutes? One?
> Not that I've started this, but if someone did, would we be fine with
> it?
I can't undestand official position of subversion developers. Obviously
this is bug because svn don't work as expected. When I write 1 line
message to log, I expect 1 line message in log. Clear and simple.
They are several patches to fix. Ones fix "svn commit", others "svn
log". Based on two opinion must or not log messages always ended with EOL.
But all patches rejected and I advised to write hook script to fix this.
I can't undestand. Can anyone explain me?
--
Olleg Samoylov
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] truncate EDITOR_EOF_PREFIX with previous EOL
Posted by kf...@collab.net.
Greg Hudson <gh...@MIT.EDU> writes:
> Well, I was expressing a preference, so I didn't try to make a formal
> argument. I thought the argument for my preference was fairly obvious:
> in the ideal case, svn:log properties should be thought of as a series
> of lines, and we should ensure that they are by requiring that they have
> a final newline.
>
> Since we can't (or at least don't want to) modify the svn:log properties
> of existing repositories, we would also append a final newline in the
> display code to svn:log properties which don't have one.
On a related note:
For Subversion's repository, how hard would it be to write a
pre-commit script that takes the log msg from the txn, removes all
leading and trailing blank lines and guarantees that the log message
ends with a single newline, and writes it back to the txn before the
commit? About fifteen minutes? Thirty? :-)
Not that I've started this, but if someone did, would we be fine with
it?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] truncate EDITOR_EOF_PREFIX with previous EOL
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2005-07-20 at 13:21 +0400, Olleg Samoylov wrote:
> Nope. It's not result of discussion. It's IMHO of one man, Greg Hudson.
> And only one his argument is:
[something vapid]
Well, I was expressing a preference, so I didn't try to make a formal
argument. I thought the argument for my preference was fairly obvious:
in the ideal case, svn:log properties should be thought of as a series
of lines, and we should ensure that they are by requiring that they have
a final newline.
Since we can't (or at least don't want to) modify the svn:log properties
of existing repositories, we would also append a final newline in the
display code to svn:log properties which don't have one.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] truncate EDITOR_EOF_PREFIX with previous EOL
Posted by Olleg Samoylov <ol...@mipt.ru>.
Michael W Thelen wrote:
> Well, it does change svn log output indirectly... the reason I
> mentioned issue #1870 is because the patch from Patrik Rådman, linked
> from that issue, looks extremely similar to yours. If you haven't
Yes, Patrik patch similar. But dangerous. Patrik don't check for begin
of the buffer.
> began as a result of Patrick's patch. That discussion resulted in
> the idea that modifying the output of svn log (by not printing
> extraneous newlines) is probably preferable to removing newlines from
> the log message itself.
Nope. It's not result of discussion. It's IMHO of one man, Greg Hudson.
And only one his argument is:
I bet that's how CVS behaves, but I'm too lazy to check. :)
--
Olleg Samoylov
Re: [PATCH] truncate EDITOR_EOF_PREFIX with previous EOL
Posted by Michael W Thelen <mi...@pietdepsi.com>.
Olleg Samoylov wrote:
> Michael W Thelen wrote:
>> Thank you for the patch... this is basically issue #1870:
>> http://subversion.tigris.org/issues/show_bug.cgi?id=1870
>>
>> If you follow the mailing list threads linked from that issue, it
>> appears that there is no clear consensus on whether trailing blank lines
>> in log messages ought to be removed.
>>
> My patch don't change svn log output and don't concern
> http://subversion.tigris.org/issues/show_bug.cgi?id=1870.
Well, it does change svn log output indirectly... the reason I mentioned
issue #1870 is because the patch from Patrik Rådman, linked from that
issue, looks extremely similar to yours. If you haven't already, it
would probably be useful to read the discussion that began as a result
of Patrick's patch. That discussion resulted in the idea that modifying
the output of svn log (by not printing extraneous newlines) is probably
preferable to removing newlines from the log message itself. Thus, the
patch in issue #1870.
--
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
Re: [PATCH] truncate EDITOR_EOF_PREFIX with previous EOL
Posted by Olleg Samoylov <ol...@mipt.ru>.
Michael W Thelen wrote:
>Thank you for the patch... this is basically issue #1870:
>http://subversion.tigris.org/issues/show_bug.cgi?id=1870
>
>If you follow the mailing list threads linked from that issue, it
>appears that there is no clear consensus on whether trailing blank lines
>in log messages ought to be removed.
>
>
My patch don't change svn log output and don't concern
http://subversion.tigris.org/issues/show_bug.cgi?id=1870.
--
Olleg Samoylov
Re: [PATCH] truncate EDITOR_EOF_PREFIX with previous EOL
Posted by Michael W Thelen <mi...@pietdepsi.com>.
Olleg Samoylov wrote:
> In log message wroten by editor always added trailing eol. This patch
> remove it.
Thank you for the patch... this is basically issue #1870:
http://subversion.tigris.org/issues/show_bug.cgi?id=1870
If you follow the mailing list threads linked from that issue, it
appears that there is no clear consensus on whether trailing blank lines
in log messages ought to be removed.
--
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
Re: [PATCH] truncate EDITOR_EOF_PREFIX with previous EOL
Posted by kf...@collab.net.
Olleg Samoylov <ol...@mipt.ru> writes:
> > * Problem (2) is that the Subversion command-line client
> > unconditionally adds a trailing eol when it *prints* log messages, to
> > make sure that multiple logs in sequence look pretty. Changing this
> > behavior is possible, but would need to be done carefully: we can't
> > just stop adding the eol, instead we'd have to refrain from adding it
> > when there is already at least one eol present anyway. Your patch
> > doesn't do this.
>
> It's not true:
> 12:24:20 olleg@archie ~/src/test
> $ svn log -r HEAD
> ------------------------------------------------------------------------
> r6 | olleg | 2005-07-18 22:59:37 +0400 (Mon, 18 Jul 2005) | 1 line
>
> test
> ------------------------------------------------------------------------
> 12:24:22 olleg@archie ~/src/test
> $
>
> Here is not trailing eol. Only blank line between revision and log
> message. You can test this by command
> svn ci -m test
(This reply is unrelated to the rest of the thread, I just want to
clarify for Olleg what I meant.)
Olleg, look at the output above:
You did "svn ci -m test" to create r6. As a result, Subversion prints
the log message for r6 as: the word "test", followed by a newline,
followed by the log message separator. That newline, the one I just
mentioned, is the one that Subversion unconditionally adds. Without
it, the output would look like this;
$ svn log -r HEAD
------------------------------------------------------------------------
r6 | olleg | 2005-07-18 22:59:37 +0400 (Mon, 18 Jul 2005) | 1 line
test------------------------------------------------------------------------
Do you see what I mean now?
The behavior change I describe above is simply to detect if the
message already ends with a newline, and not add any newline if so.
Thus, Subversion would do this (which I don't think is a good idea, by
the way):
$ echo -n "test" > logmsg
$ svn ci -F logmsg
[...]
Committed revision 6.
$ echo "test" > logmsg
$ svn ci -F logmsg
[...]
Committed revision 7.
$ svn log -r 7:6
------------------------------------------------------------------------
r7 | olleg | 2005-07-18 23:00:00 +0400 (Mon, 18 Jul 2005) | 1 line
test
------------------------------------------------------------------------
r6 | olleg | 2005-07-18 22:59:37 +0400 (Mon, 18 Jul 2005) | 1 line
test
------------------------------------------------------------------------
$
I am not proposing we do this. However, it has been discussed briefly
in the distant past, that's why I had it in mind when I was
determining what problem you had solved. Probably I shouldn't have
listed it, it only confused matters.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] truncate EDITOR_EOF_PREFIX with previous EOL
Posted by Branko Čibej <br...@xbc.nu>.
Olleg Samoylov wrote:
> Yes, I take exactly same code to detect EOL from current source.
> But may be better use apr_isspace(char)? And remove not only EOL but
> trailing space also?
Actually, since the log messages are in UTF-8, you should be using the
svn_ctype macros everywhere, including when you check for \r and \n (and
so should the rest of the code, of course -- we still have lots of
places where we don't behave nicely).
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] truncate EDITOR_EOF_PREFIX with previous EOL
Posted by Olleg Samoylov <ol...@mipt.ru>.
kfogel@collab.net wrote:
> * Problem (1) is that some text editors always add a trailing eol.
> If you don't want the trailing eol, the solution is not to change
> Subversion, but to use a different editor (or configure your editor
> differently, or write a script to fix up the message in a file
> afterwards, or whatever.) I'm using "eol" to mean "whatever sequence
> of characters represents end-of-line on the client system", by the
> way.
Yes, some editors place EOF only after EOL. IMHO most editors do this.
May be except hex editors. :-)
> * Problem (2) is that the Subversion command-line client
> unconditionally adds a trailing eol when it *prints* log messages, to
> make sure that multiple logs in sequence look pretty. Changing this
> behavior is possible, but would need to be done carefully: we can't
> just stop adding the eol, instead we'd have to refrain from adding it
> when there is already at least one eol present anyway. Your patch
> doesn't do this.
It's not true:
12:24:20 olleg@archie ~/src/test
$ svn log -r HEAD
------------------------------------------------------------------------
r6 | olleg | 2005-07-18 22:59:37 +0400 (Mon, 18 Jul 2005) | 1 line
test
------------------------------------------------------------------------
12:24:22 olleg@archie ~/src/test
$
Here is not trailing eol. Only blank line between revision and log
message. You can test this by command
svn ci -m test
> * Problem (3) is that when you write a log message by allowing
> Subversion to invoke an interactive editor, Subversion places a list
> of changed files at the end of the buffer, and promises to
> automatically remove that list. However, when it removes the list,
> it still leaves the eol that preceded the list.
Yes, it's look like bug. When I write one line message on commit in
editor, message created with two line.
> Since having a trailing eol on a log message is normally considered
> desirable, I think this is a good default behavior for Subversion,
Some like output "svn log" with trailing blank line, some without.
Output of "svn log" must be convenient or customizable, but it's not
matter of this patch.
When I write one line log message, I expect one line log message. I expect:
$ svn log -r HEAD
------------------------------------------------------------------------
r6 | olleg | 2005-07-18 22:59:37 +0400 (Mon, 18 Jul 2005) | 1 line
~~~~
How many blank line may add "svn log" or other subversion client is
other question.
> especially since it's easy to work around -- just remove the change
> list using your editor, making sure to remove the preceding eol as
> well (this assumes your editor doesn't have Problem (1), of course).
Another workaround is use "svn commit --message" and don't use buggy
support of editor. :-)
If a bug have a workaround it don't begin looked like a customizable
feature. :-)
> Based on where you made the patch, I guess you are trying to solve
> problem (3) only.
Fix bug "problem(3)" and try workaround problem(1).
> The actual behavior change is a bit more sophisticated than what you
> wrote, however. Saying that you are removing "the trailing eol" is
> unclear, since at the time the input goes into the function, that eol
> is not trailing (it is somewhere in the middle of the string). Say
> instead "Avoid leaving a trailing eol on the result.", or something
> like that.
English is not my native language and I speak as I can. Anyone free to
change my log message to something better.
> There was a formatting problem, I think: the "+" right after the
> "else" should have begun a new line, right?
Yes, thanks. Strange, I simple copied from xterm to thunderbird. May be
mistype.
> Also, this algorithm is not sophisticated enough. What if you
> encounter '\r' or '\n' as independent characters in a log message,
> not as part of an eol sequence (on Windows at least, '\n' can stand
> alone outside an eol sequence; on Unix it's always eol, of course).
>
> Of course, the current code has the same bug, which is not your fault
> at all.
Yes, I take exactly same code to detect EOL from current source.
But may be better use apr_isspace(char)? And remove not only EOL but
trailing space also?
> Finally, you changed the behavior of truncate_buffer_at_prefix(), but
> you did not change its doc string. Don't make the doc string lie
> :-).
Yep, my fault. When I get clear answer about apr_isspace(char) I
resubmit patch.
--
Olleg Samoylov
Re: [PATCH] truncate EDITOR_EOF_PREFIX with previous EOL
Posted by kf...@collab.net.
Olleg Samoylov <ol...@mipt.ru> writes:
> In log message wroten by editor always added trailing eol. This patch remove it.
>
> --
> Olleg Samoylov
>
> [[[
> * subversion/clients/cmdline/util.c
> (truncate_buffer_at_prefix): Remove trailing eol from log message.
> ]]]
There are several unrelated problems you could be solving here. It
would be best to describe the problem precisely.
* Problem (1) is that some text editors always add a trailing eol. If
you don't want the trailing eol, the solution is not to change
Subversion, but to use a different editor (or configure your editor
differently, or write a script to fix up the message in a file
afterwards, or whatever.) I'm using "eol" to mean "whatever
sequence of characters represents end-of-line on the client system",
by the way.
* Problem (2) is that the Subversion command-line client
unconditionally adds a trailing eol when it *prints* log messages,
to make sure that multiple logs in sequence look pretty. Changing
this behavior is possible, but would need to be done carefully: we
can't just stop adding the eol, instead we'd have to refrain from
adding it when there is already at least one eol present anyway.
Your patch doesn't do this.
* Problem (3) is that when you write a log message by allowing
Subversion to invoke an interactive editor, Subversion places a list
of changed files at the end of the buffer, and promises to
automatically remove that list. However, when it removes the list,
it still leaves the eol that preceded the list. Since having a
trailing eol on a log message is normally considered desirable, I
think this is a good default behavior for Subversion, especially
since it's easy to work around -- just remove the change list using
your editor, making sure to remove the preceding eol as well (this
assumes your editor doesn't have Problem (1), of course).
Based on where you made the patch, I guess you are trying to solve
problem (3) only. As explained above, I don't think this change is
necessary. However, here is a review of the change:
First, thank you for well-formatted log message!
The actual behavior change is a bit more sophisticated than what you
wrote, however. Saying that you are removing "the trailing eol" is
unclear, since at the time the input goes into the function, that eol
is not trailing (it is somewhere in the middle of the string). Say
instead "Avoid leaving a trailing eol on the result.", or something
like that.
Regarding the patch itself:
> Index: subversion/clients/cmdline/util.c
> ===================================================================
> --- subversion/clients/cmdline/util.c (revision 15361)
> +++ subversion/clients/cmdline/util.c (working copy)
> @@ -417,6 +417,14 @@
> || (*(substring - 1) == '\r')
> || (*(substring - 1) == '\n'))
> {
> + /* Remove previous eol. */
> + while (substring != buffer)
> + if ((*(substring - 1) == '\r')
> + || (*(substring - 1) == '\n'))
> + substring--;
> + else + break;
> +
> *substring = '\0';
> if (new_len)
> *new_len = substring - buffer;
There was a formatting problem, I think: the "+" right after the
"else" should have begun a new line, right?
Also, this algorithm is not sophisticated enough. What if you
encounter '\r' or '\n' as independent characters in a log message, not
as part of an eol sequence (on Windows at least, '\n' can stand alone
outside an eol sequence; on Unix it's always eol, of course).
Of course, the current code has the same bug, which is not your fault
at all.
Finally, you changed the behavior of truncate_buffer_at_prefix(), but
you did not change its doc string. Don't make the doc string lie :-).
Best,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org