> 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  "3. You'll get a text prompt about the server's certificate, asking you what to do4. 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.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 trustedIn 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 " " -- 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.-==-Jack Repenningjackrepenning at tigris dot orgProject OwnerSCPlugin"Subversion for the rest of OS X"