> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: zondag 26 mei 2013 08:49
> To: [email protected]
> Subject: svn commit: r1486397 - /subversion/branches/1.8.x/STATUS
>
> Author: danielsh
> Date: Sun May 26 06:48:49 2013
> New Revision: 1486397
>
> URL: http://svn.apache.org/r1486397
> Log:
> * STATUS: Ask a question about r1485127.
>
> Modified:
> subversion/branches/1.8.x/STATUS
>
> Modified: subversion/branches/1.8.x/STATUS
> URL:
> http://svn.apache.org/viewvc/subversion/branches/1.8.x/STATUS?rev=1486
> 397&r1=1486396&r2=1486397&view=diff
> ==========================================================
> ====================
> --- subversion/branches/1.8.x/STATUS (original)
> +++ subversion/branches/1.8.x/STATUS Sun May 26 06:48:49 2013
> @@ -104,6 +104,10 @@ Candidate changes:
> Restores functionality that was lost in 1.8 compared to 1.7.
> Votes:
> +1: rhuijben (for 1.8.1 or soak restart)
> + +0: danielsh (looks right, but all this does is cause sess->repos_url
> + to be set to a non-canonical value; I wonder if the right
> + fix is to add a canonicalize() call in front of a strcmp()
> + in libsvn_client)
I wish it were that simple.
The usage of file://localhost/some/location to a repository on /some/location
has been hardcoded in ra_local since before 1.0, but is not part of our
canonicalization rules in svn_uri_canonicalize().
The 'simple fix' to change the canonicalization rules by including this rule
would require a working copy format bump, as this prefix is currently perfectly
valid as a repository location. And then for this example the api works for us,
but is not really part of any RFC.
That 'localhost' refers to the local machine is a convention on many platforms,
but not really a standard.
On Windows we also have file:///some/path urls that refers to E:\some\path when
E: happens to be the current harddrive. And this has similar conversion
problems.
I think that for 1.8 we have to keep the same one to many relation between
local dirents and repository urls, as in 1.0-1.7 :(
For 1.9+ we might be able to apply new canonicalization rules via a proper
upgrade, but doing this now would just delay 1.8, at no real gain for our users.
Bert
>
> * r1485447, r1485449
> Make 'SQLITE_VERSION=3.7.15.1 ./get-deps.sh' work.
>
