Issue 1770 and get_repos_root

Hi,

I'm owrking on issue 1770 which is caused by get_repos_root not returning
an URI-encoded URL in some ra_svn (and ra_local before an earlier commit
by me).

As it tursn out, the code that failed tryed to get the FS path by
removing the first strlen(repos_root) bytes from the URL used to open the
RA session, then URI-decoding the rest. Luckily, this code is now only
used as fallbacks for missing get_locations and get_file_revs RA
functions on 1.0 servers, so for 1.1 this bug seems to have disappeared
as a side-effect of other development.

Still, there is a bug in libsvn_ra_svn sending a decoded URL, which I
want to fix, which in itself would be simple. But just URI-encoding the
path doesn't make the returned URL a prefix of the URL used to open the
session, since you can URI-encode characters that strictly doesn't need
to be encoded (%41 is a valid way to say A, for example). This is
somewhat unusual, but we can't just hope that everyone will URI-encode
like svn_path_uri_encode does (I am thinking of colons in paths for
example). I have a solution to this which involves counting the number of
segments in the FS path and removing that number of segments from the URL
used to open the RA session.

Now, the question is just what get_repos_root is supposed to return:
- the part of the RA session URL that represents the repository root
(guaranteed to be a prefix of the URL used to open the session)
or
- A URL representing the root of the session (not guaranteed to be a
prefix of the URL)

Our fallback code relies on the first interpretation, but that code is
only used on currently buggy 1.0 servers. Unless we want to backport this
(probably not), this isn't very relevant. ON the other hand, we may want
to be able to determine the FS path in the future without having to
introduce an RA layer function for that.

Any opinions? BTW, the attatched patch shows the solution with the first
intepretation if anyone is interesting.

Enough written for this time. Sorry for the long post..

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org