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.
>eg svn:ignore=
> *.o
> *.a
> *.obj
> *~
> *.tmp
>
>
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
example, svn_config_get_bool().
>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
value lists?
Instead of
svn:ignore=
foo
bar
we could also accept
svn:ignore=@list("foo", "bar")
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(...)")).
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 8 18:36:40 2005