When trying to access a SVN repository using the svn+ssh protocol with TortoiseSVN it might happen that the password prompt shows up endless times. One suggested solution is to set up a profile in putty and use a private key for authentication for ssh there. Then in TortoiseSVN the host name just has to be changed to the name of the profile, e.g. svn+ssh://username@puttyProfileName/path/to/repo.
This works well until trying to reuse the stored SVN information of your local working copy in another client, for example your IDE. In my case I am using Eclipse with the Subclipse plug-in and my first approach didn’t work with Subclipse, which meant I couldn’t do any team actions from Eclipse when the projects where checked out using TortoiseSVN. If you are only using either of them it works fine.
The solution is quite simple: Rename the putty profile to the actual hostname and use the regular URL for the repository. That’s it. If you’ve used the putty profile name before just use relocate in TortoiseSVN to change the repository URL. TortoiseSVN will then still use the putty profile with the private key to authenticate. Other clients like Subclipse see it as an actual hostname and are able to use that.
A few weeks ago I helped a friend with an issue he had on an iMac with the Wi-Fi. After a while AirPort stopped from connecting automatically to the Wi-Fi. Although this can be caused by various different issues I want to describe the one I found. All the other instructions can be easily found on the web with the search engine of your choice.
The Wi-Fi uses a hidden SSID which can cause problems, not in this case though. Although it doesn’t really increase the security (because there are tools you can use that reveal it) it can help on a social basis when people just shouldn’t see that there is a Wi-Fi.
Anyways. As a side note: There were two iMacs set up the same way. One worked fine but the other didn’t so something must have been different. A lot of advices didn’t help but they could help in your case. In this case the problem was caused by the fact that the SystemPreferences application was moved out of it’s original place. After moving it back to the Application directory (/Applications) and restarting it worked fine again. I am assuming this could cause more problems than the one described here.
Do you have to accept the the End-User License Agreement (EULA) of your Office applications every time you start them even though you’ve accepted them already? This might be because you are using a restricted user account and thus the change can’t be written into the Windows registry.
To solve this log in with an Administrator account and perform the following steps for all Office applications you are using: Open the application, accept the EULA and close the application again.
If you log in with your user account again the EULA should not appear again. If it doesn’t work try to modify the permissions in the registry described in this knowledge base article.