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

Re: svn commit: r1481628 - /subversion/trunk/subversion/libsvn_repos/commit.c

From: Stefan Sperling <stsp_at_elego.de>
Date: Mon, 13 May 2013 00:42:55 +0200

On Sun, May 12, 2013 at 10:48:37PM +0200, Bert Huijben wrote:
> [Not really targeted to this specific commit, but I don't see the real
> revision that introduced this code... Maybe some 'following up' would
> improve the log message]

See r1461760. It's easy to find in the log since the name of the
removed function is given in log message. And you could also use
'svn praise' :)

> Is it a requirement for all error creators to escape all valid but
> unexpected characters, or should console specific clients such as
> 'svn' make sure their error output doesn't contain unexpected escape
> characters?

I'm not sure. This function is in libsvn_subr, it can be called
from many contexts.

> In this specific case I'm pretty sure that the error will actually
> just go to the user, but in general I would be -0.5 on performing this
> kind of escapes in the creation of error messages that are part of our
> libraries that are also used by GUIs and bindings that might want to
> apply different handling and see the raw values.

I see your point. I think we could choose to send the literal value
to the client. Worst case is that a user might not be able to
immediately see why a commit is failing, in case processing the
message fails somewhere because of other bugs.

However, I also think it's fine to be careful here and substitute
control characters. This case will rarely be hit in practice.
Else we would have found the issue #4340 problem much sooner.
Received on 2013-05-13 00:43:32 CEST

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.