On SVN, sf.net and MacOSX
Just a short note to everybody who is struggling with either (or both) problems:
* since only recenly was unable to use your sourceforge.net hosted subversion account with strange response 403
* was trying to use SCPlugin for MacOSX with https:// repositories without success
The solution to the first problem is pretty simple – you are probably using http://…sf.net/... address for your repositories – this is no longer supported.
To solve your problems – do
svn switch –relocate http://…... https://…….
The second problem might (as in my case) arise from the SSL certificate problems with the subversion server. If you enter your repository URL to the web browser and it asks you to confirm the certificate than this is exactly the problem I was facing, and … good news – here is the solution for you. Apparently SCPlugin still cannot ask you to confirm the certificate through GUI, so you have to do it yourself manually.
The easiest way is to call
svn ls https://…..
and answer (p)ermanently to the given question.
However, since neither MacOSX (Leopard 10.5.4) nor Fink provides subversion in the new (backward incompatible!), endorsed by sf.net version 1.5 you might consider using the one (1.5.1) provided by SCPlugin at the following location:
/Library/Contextual\ Menu\ Items/SCFinderPlugin.plugin/Contents/Resources/SCPluginUIDaemon.app/Contents/bin/svn
The new SmartSVN 4 is also compatible with SVN 1.5 so your command line SVN might soon be incompatible with your repositories (if you use SmartSVN 4 at least once with this repository!)
On AJAX problems with prototype.js v1.5+ (till 1.6.0.2 at least)
My (a little tiring now) work on JOnto 2.0 is getting closer to the finish line. I can almost see the crowd cheering.
Many changes, including WordNet in RDF/OWL and OpenThesaurus (non-English thesauri) support, full-text index, etc.
I decided to check the current version (let’s call it JOnto 2.0 PR 1) with the most recent prototype.js.
To my surprise it did not work. Hanged with no logs whatsoever (as usually with prototype.js).
The bug was not, however, in my code.
It took me a while to recall the details of this deja-vu feeling.
To make sure I will not forget it next time, and for other people to know what is going wrong, here a short description:
If you catch exception with onException(resp, ex) you will see that your script is trying to perform illegal operation.
Firebug reports “Component returned failure code: 0×80070057”
Safari is a little more precise – reports problems with an attempt to set illegal header in the HTTP request.
Where is the bug?
Apparently since prototype.js v1.5, i.e., the first time I have discovered it (since it worked in v1.4) the setRequestHeaders method uses following implementation:
for (var name in headers)
this.transport.setRequestHeader(name, headers[name]);
which does not catch any exceptions
My fix is the following, change this two lines to
var transport = this.transport;
$H(headers).each(function (header){
try{
transport.setRequestHeader(header.key, header.value);
}catch(ex){
// YAHOO.log(header.key, header.value, ex);
}
});
The question remains how is that possible that some invocations of Ajax.Request do and some don’t produce this problem.
For now – I’d rather patch the script and live on.
