Ph. Marek wrote:
>On Friday 08 April 2005 10:32, Branko Čibej wrote:
>>Ph. Marek wrote:
>>>svn:ignore needs newlines.
>>Eh? I though we decided long ago that we won't support weirdness, e.g.
>>newlines, in file names.
>They're not part of the filenames, but seperate the patterns for filenames.
O.K., I see it now. Sorry for being dense.
>1: It's very good if a configuration file is parsed in one way, and only one.
>Handling some parts with escaping and others without leads to confusion.
I think you're confusing "parsing" and "interpreting the results". We
already have different ways of interpreting the results; see, for
>2: I don't know what can break if there are special characters in other
>parameters, especially as svn_string uses a length field, but much internal
>handling still happens on the ->data directly and is \0-sensitive.
>That's why I asked if NUL characters should be disallowed in unescaping.
Do we want to autoprop binary properties? I'd guess not.
>All in all, I believe that having 1 is of higher priority than 2.
>In most cases it's much harder to adapt users to something than to adapt some
>program to the users.
I think all your examples are about lists of values, rather than about
escaping in general. For example, when setting svn:ignore, you want a
list of values, not necessarly a newline-separated list. What if,
instead of an escaping scheme, we come up with an additional syntax for
we could also accept
The list items enclosed in quotes could be subject to escaping (e.g.,
for the quites themselves). Something like this could be done in a
completely backward-compatible way (except for the pathologic case where
someone actually wants to ignore a file named @list(...); but the
workaround for that is @list("@list(...)")).
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Apr 8 18:36:40 2005