> -----Original Message-----
> From: Guido Wischrop [mailto:Guido.Wischrop_at_mgm-tp.com]
> Sent: vrijdag 4 april 2014 15:07
> To: users_at_subversion.apache.org; dev_at_subversion.apache.org
> Subject: Re: svn: E170000: 'https://user:pass@x' isn't in the same
repository
> as 'https://user:XXXXXXXX@x'
>
>
> On 03.04.2014 12:47, Philip Martin wrote:
> > Guido Wischrop <Guido.Wischrop_at_mgm-tp.com> writes:
> >
> >> I'm using win32svn, version 1.8.5 (r1542147) in Windows 7 x64 like
this:
> >>
> >> svn checkout https://user:pass@server/svn/p1/trunk
> >>
> >> I get the following error immediately:
> >>
> >> svn: E170000: 'https://user:pass@server/svn/p1/trunk' isn't in the same
> >> repository as 'https://user:XXXXXXXX@server/svn/p1/trunk'
> >>
> >> I tried SlikSVN (svn, version 1.8.5-SlikSvn-1.8.5-X64 (SlikSvn/1.8.5)
> >> X64) with the same result.
> >>
> >> With version 1.7.1 or 1.6.5 (SlikSVN 1.7.1/win32svn) the same command
> >> works as expected. Is the user:pass_at_server scheme no longer
> supported?
> > I get the same problem with trunk on Linux. I can fix it with this
> > patch but I'm not sure I understand all the consequences. Is there any
> > reason we should be hiding the password here?
> >
> > Index: subversion/libsvn_ra_serf/options.c
> >
> ==========================================================
> =========
> > --- subversion/libsvn_ra_serf/options.c (revision 1584323)
> > +++ subversion/libsvn_ra_serf/options.c (working copy)
> > @@ -245,7 +245,8 @@
> > (char *)svn_fspath__canonicalize(val, session->pool);
> > session->repos_root_str =
> > svn_urlpath__canonicalize(
> > - apr_uri_unparse(session->pool, &session->repos_root,
0),
> > + apr_uri_unparse(session->pool, &session->repos_root,
> > + APR_URI_UNP_REVEALPASSWORD),
> > session->pool);
> > }
> > else if (svn_cstring_casecmp(key, SVN_DAV_ME_RESOURCE_HEADER)
> == 0)
> >
> >
>
> So is this considered to be a bug? Is there another workaround as using
> --user --password?
As far as I can tell we only really support a username in the url for
svn+XXX:// urls. In some other cases we just passed 'the unsupported' url to
the lower layers and the neon library (our <= 1.7 default) completely
ignored this, while serf (which we use as default since 1.8) tried to use it
as the hostname.
I would really recommend not using a username in the url this way... You
just store the password unencrypted on your disk in a place where it isn't
even really used.
It also breaks using 'svn cp WC WC2' where WC and WC2 have a slightly
different authentication id.
And as Subversion doesn't actually use the username and password from the
url, they won't be updated if you ever want to change your password (or use
the working copy as a different user)
Bert
>
> Thanks,
> Guido
Received on 2014-04-04 17:41:45 CEST