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: dev_at_subversion.apache.org
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.
Received on 2012-01-21 08:32:13 CET