attached is a patch for this issue. The patch is implemented by converting
the hostname to lowercase path.c/svn_path_canonicalize. This should make
sure that all internal handling of URI's is done with a lowercase hostname.
Is that what you suggested?
A consequence of solving the issue like this is that the URI in the entries
file should now be stored with a lowercase hostname. Working copies created
with a pre-this-patch svn client with uppercase hostnames in their entries
files are not supported anymore.
I could add a temporary solution to automatically convert hostnames to
lowercase in those entries. Other ( and better in my opinion ) option is to
include this patch in a release that bumps the version of the entries file.
Are there other options?
> -----Original Message-----
> From: Branko ╚ibej [mailto:firstname.lastname@example.org]
> Sent: woensdag 8 maart 2006 2:07
> To: Lieven Govaerts
> Cc: email@example.com
> Subject: Re: Hostnames should be case-insensitive - tryiing
> to solve issue 2475
> Lieven Govaerts wrote:
> > Hi,
> > I started working on issue 2475. The problem reported in
> that issue is
> > that hostnames in URIs should be case-insensitive ( as per
> RFC3986 ).
> > The problem surfaces when two URLs are compared. E.g. when
> a file is
> > copied from one folder to another, a case-sensitive check is done
> > wether source and target folders are from the same repository.
> > Now, I've checked the code for places where this type of
> test is done,
> > and I found some 30 instances of strcmp & strncmp where URLs are
> > involved. Most of them in libsvn_client and libsvn_wc, some
> in libsvn_ra* and libsvn_repos.
> > I see some possible options to solve this:
> > Option 1. Make lowercase of all the hostnames in all the
> URLs on entry
> > point in the code, don't touch the case-sensitive checks. Maybe the
> > easiest solution, but not very clear in error messages etc.
> > Option 2. Replace all the strcmp and strncmp calls ( only
> those where
> > URLs are compared ) with their case-insensitive equivalents.
> That would be wrong; the path part of the URL is *not*
> > Option 3. Create one new function url_compare() where a correct,
> > standards-compliant URL comparison is implemented, use that
> > in all places where strcmp/strncmp is used now. What would
> be a good
> > place to define such a function?
> > I prefer option 3 myself. Maybe there are other and better options?
> > Anybody any thoughts on the subject?
> Option 4. Follow the conventions we already use for paths:
> i.e., the API expects all path parameters in canonical form.
> Define the canonical form for URLs so that the hostname part
> must be lowercase (but only the host name, not the optional
> embedded user name). Document that, then perform the URL
> canonicalisation in the client code, as we do with file names --
> *not* in the library code.
> -- Brane
Received on Sat Mar 11 23:59:52 2006
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com