> PROPFIND request failed on '/svn/Superscout'
> PROPFIND of '/svn/Superscout': Server certificate verification
> failed: certificate issued for a different hostname, issuer is not
> trusted (https://XX.XX.XX.XX)
===========================================================
出现以上提示时,使用以下方法
===========================================================
First, here's how to fix the situation:
1. Open Terminal (in Utilities, in Applications)
2. Type some svn command against your repository, say "svn ls https://82.100.10.110/svn/Superscout
"
3. You'll get a text prompt about the server's certificate, asking you
what to do
4. Type "p" (and return), meaning "permanently accept this certificate
anyway"
That answer will be saved away in a place that both the command line
"svn" and also SCPlugin will reuse.
===========================================================
1 启动中端
2 输入类似: "svn ls https://82.100.10.110/svn/Superscout ",我们的svn服务为:https://192.168.8.3/svn/
所以请输入: svn ls https://192.168.8.3/svn/Superscout
4 出现提示时, 输入"p",回车
5 后面输入下mac系统用户密码, 和svn的用户名和密码即可
猜测: mac下的svn无法清除原来的用户名和密码, 能找到其中的配置文件并删除应该是可以清楚的,
可以试下这个方法是不是可以用来修改svn的登录用户名和密码, 我没验证过...
===========================================================
Now, the explanation, in case you're curious:
You're accessing Subversion through the HTTP protocol, the same one
used by web browsers. This is probably the most common way to use SVN.
HTTP servers can, and often do, use an encrypted connection, called
"https". Subversion can do that, too, and that's what's going on here.
The encryption includes a "server certificate," a digital signature
that proves that the server you're talking to really is the one you
think it is. This is included because it is possible to arrange so
that connections you think are going to one computer actually go to
another. There's an attack called the "man in the middle," where some
bad person sets things up this way, then forwards messages back and
forth between you and the true server. Your web browser (or
Subversion) sends and receives exactly the packets it expects to, but
the "man in the middle" is reading everything. Unfortunately, there is
no way to detect or prevent this from the stream of messages alone.
The server certificate protects you against this, because the server
certificates are digitally signed by someone else. The idea is that
there should be a few signatories that you trust to do this, and you
can confirm that one of these signed a given server's certificate, and
hence you trust that it's the one you want. This is the same as
checking a person's driver's license: you trust the state to attest
who the person is; you've seen driver's licenses before and can spot a
phony (at least, if it's not too good a phony), and so having seen the
license, you can trust that the person is who they claim to be.
This process isn't working for you. The messages actually say there
are two problems:
- certificate issued for a different hostname
- issuer is not trusted
In the first problem: if I claim to be "Jack Repenning," and attempt
to prove that by showing you a license for "Fred Smithers," you'd be
more than a little suspicious, right? Same thing here. However, this
is probably because you told Subversion to contact "https://82.100.10.110
" -- that is, the server's "name" is 82.100.10.110. That's the host
*address*, but typically the server's actual certificate is for their
host *name*. If you try again, using "https://
server.superscout.co.uk" (or whatever the name actually is), this part
will probably go away. But maybe not: when I try to look up that
address in the global DNS name base, I don't get a reply. Probably
that address is internal to your company network, and so conceivably
you may not have DNS properly set up for it. Maybe that's why you used
an address rather than a name. At any rate, the procedure above will
reassure Subversion that this combination really is OK.
In the second problem: metaphorically, Subversion is saying "this
looks like a driver's license, but it's from some country I've never
heard of, how do I know whether it's a valid license from there?"
Actually, there's a good chance that this certificate is signed by one
of the standard authorities: there's a bug in OS X about the
installation of this information, as a result of which Subversion (and
SCPlugin) requires some extra configuration work in order to find the
list of trusted authorities. If you're going to be connecting to a
great many different servers, it might be worth your while to fix
this. That can be done, but until Apple fixes the bug it also means
you have to manually update it from time to time (about once a year),
which would be tiresome.
The procedure above works once for all time, for this one address. If
you only have to do it a few times, you're better off just doing it
than fixing the authority list. But if you want to fix up the list,
you can find the directions in the users@ list on scplugin. Or, just
ask there again, and someone will restate them, or point you to them.