We fixed : and * soon after 1.5 by scanning backwards from \n, but control characters and \r and \n are quite impossible in the current mergeinfo format.
Bert Huijben (Cell phone) From: Daniel Shahaf Sent: 21-1-2012 4:47 To: Garret Wilson Cc: [email protected] Subject: Re: URI-encoding on 1.7 repository? Garret Wilson wrote on Fri, Jan 20, 2012 at 19:27:12 -0800: > On 1/20/2012 7:00 PM, Daniel Shahaf wrote: > >Garret Wilson wrote on Fri, Jan 20, 2012 at 18:18:24 -0800: > >>On 1/20/2012 6:14 PM, Daniel Shahaf wrote: > >>>You don't care what FS backend the server runs. All you care is > >>>that the endpoint of svn_ra_open4() implements the Subversion RA > >>>API properly. Normal Subversion servers use svn_fs.h which in turn > >>>presents the same API _regardless of which backend is used_. I'll > >>>spell it out: the notion of 'valid pathname in a Subversion > >>>filesystem' does not depend on the FS backend in use. > >>All that is good news. So I guess the important question is: what > >>spells out "the notion of 'valid pathname on a Subversion > >>filesystem'"? Is it "any valid Unicode code point?" What I'm getting > >See my previous reply. > > Right. So your previous reply said that a "valid pathname" is the > same on all platforms, and that the underlying implementation will > take care of the details. I'm asking what are the rules for a "valid > pathname". I'm glad that these rules are the same across all > platforms, but I don't know what the rules are. In other words, what > goes in the following function? > > boolean isValidSubversionPathname(String pathname); > http://svn.haxx.se/dev/archive-2012-01/0292.shtml -> https://svn.apache.org/repos/asf/subversion/tags/1.7.2/subversion/libsvn_fs/fs-loader.c#line-293 > > > > >>at is that I need to know which characters, if any, I need to encode > >>before passing them to Subversion. If Subversion supports any > >>Unicode character, I can just pass the path decoded and sleep > >>soundly at night. If not, I need to know which ones to decode and > >>which ones to pass through. > >Err, that depends on what API layer you're working with. (For example: > >svn_fs.h is perfectly happy with :,*,\n as part of the basename, but > >libsvn_wc on windows, and the mergeinfo logic, aren't.) > > Oh, that's bad news. In your previous reply you said, "the notion of > 'valid pathname in a Subversion > filesystem' does not depend on the FS backend in use." Now you seem > to say "whether some pathname is valid or not it depends on whether > you 're on Windows or some other platform." No. I said that "* is a valid pathname character in the Subversion filesystem", and that assertion is true on Windows too. You're welcome to grep for '#ifdef WIN32' in subversion/tests/*_fs/. > (Even worse, you seem to be saying that the notion of "valid pathname" > isn't even consistent across the API.) Yes. If a pathname contains "*" or ":", it is my understanding that trying to set mergeinfo on that path won't work well. (I haven't tried to reproduce this, but it would be trivial to do so on a Unix-y system.) See svn_mergeinfo_to_string(). > > >And 'what to encode/decode' is a rather vague question. I'm not sure if > >it means "Does `svn info uri:///foo bar` == `svn info uri:///foo%20bar`?" > >or something else. Can you be more concrete? > > It doesn't matter. It's some black box that works like this: > > String encode(String input); > String decode(String output); > > I can come up with a thousand ways to encode/decode. I can use %hh. > I can use ^0xhh. The only two requirements are that 1) encode() > provides me with a string guaranteed to be a valid pathname, and 2) > decode() will take the encoded string and give me back the decoded > string I started with. > > But to meet requirement #1, I have to know which characters are > considered valid and which aren't. That's what I don't know, and > that's what I'm asking: > > 1. Does the API guarantee that a "valid pathname" (whatever that is) is > the same across all platforms? I thought you said yes, but now it > seems you're saying no. (If you say "no", then there's no point in The answer is "Yes" for all server-side API's.
