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
> > I expect that some user-defined file-property could
> >need special characters too;
>
> Subversion doesn't interpret user-defined properties. Some sort of user
> app does that. The "unescape string" function could be a public API in
> libsvn_subr, thus available to such a user app.
That's right.
But there should be a way to insert special characters into properties, and it
should be possible with auto-props as well.
> > I'd like to behave auto-properties the same for
> >files and directories, it's hard to explain why some things would be
> >un-escaped and others not.
>
> I still don't understand why we need escaping in auto props.
svn:ignore has patterns, which are seperated with newlines.
There is currently no way to insert newlines in auto-props, so there has to be
some extension.
> >I'd say, that the packagers (eg. debian) should test for this case and
> > provide some support for that.
> >But you're right, on upgrade it's very likely that something will break.
>
> Indeed. And we've never relied on packagers for backward compatibility,
> and I hope we don't start now.
And lots of people will just copy binaries. I know that it's not good, that's
why I told about the openssh-way of changing configuration files.
> >OpenSSH solved a similar problem by using a "authorized_keys2" file
> > instead of "authorized_keys", which was parsed some other way; and by now
> > they've deprecated the old format, and both files are parsed the same
> > way.
> >
> >So possibly we should a "config2" file which has this parsing - people who
> >need that, can rename the file and change the contents.
> >
> >
> >Do Python config files support any way of escaping?
>
> Not according to the Python manuals.
So there's no way to stay compatible with Python _and_ have special
characters. Ok.
> >I've thought about other encoding schemes, but it's always possible (and
> >sometimes likely) that something will break.
>
> Yes. That's why I really, really suggest we have a separate unescape
> function. I wouldn't even object to a svn_config_get_unescaped that
> would automatically call the unescape function before returinig the
> data, but I'm adamantly -1 on the idea that _all_ config values were
> unescaped during parsing.
I'm in two minds about that.
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.
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.
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.
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 8 11:08:44 2005