[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [Issue 1770] non-ascii path truncated by 'svn blame'

From: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2004-06-09 19:44:12 CEST

On Wed, 9 Jun 2004 sussman@tigris.org wrote:

> ------- Additional comments from sussman@tigris.org Tue Jun 8 19:51:14 -0700 2004 -------
> Assigning to 1.1-consider as part of the 1.1 issue-sweep. Peter seems to have
> this bug mostly fixed already.
>
>
The problem is that I think the fix is bogus. It works as long as the
users encodes the URI like svn_path_uri_encode does. But this isn't
necessarily the case. Try checking out a repository with some ASCII
letters %-encoded. Then use svn ls or something. Since the client relies
on the ra_lib->get_repos_root returning a prefix of the URI it passed when
it opened the RA session, it will use too much of the string which now is
svn_path_uri_encoded to a shorter string.

I think we either have to "normalize" incoming URLs, but making sure this
is done correctly might be tricky. Else, we can avoid reencoding the URL
and instead send a prefix of the original string. But then
svn_repos_find_root_path wants a path and not a part of an encoded URL...

I've been considering counting the number of path components returned by
svn_repos_find_root and make sure that the path part of the URL (which we
already have) has the same number of components. This ought to work, since
a slash is always a slash. It would be nice to have a function (or two) in
svn_path.h that do this, since it is needed in all three RA
implementations.

I don't think this should block 1.1, so how to procede? Should I revert
9931 or keep it since it works in many situations, noting that we need the
real fix in 1.2?

//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 9 19:57:46 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.