We have had some trouble with a "standby" (backup) slave this weekend.

We experienced a short power loss across our server infrastructure, and in the subsequent automatic reboots an offline "standby" (virtual) slave has also been mistakenly powered on - allowing it to receive direct traffic intended for the main server. When the standby-slave periodically synced from its master, any changes recieved by slave directly was cleaned out.

Your changes between Sunday January 31st ~04:00 CET and Monday February 1st 14:00 CET may be affected by this. Please check your project to see if anything is missing.

If you have committed new revisions to a repository, or updated your working copy with changes from others, your local working copy may well be out of sync. The safest option is to check out a new, clean working copy and then transfer any missing changes to the new working copy and commit them there. Please Contact Us if you are unable to resolve this easily, and we'll help you take corrective actions.

For any non-repository changes and registrations affected by the incident, the only real solution is to re-type and post the new/updated information.

We are really sorry for any inconvenience this may have caused you, and have now taken measures to prevent this situation from arising again.

We experienced an unexpected downtime this afternoon - roughly from 16:00 CET to 17:00 CET. The error occured when a new planned link was configured by our ISP before it was planned to be physically connected, making it impossible to reach our network.

After locating the error we also then connected the new fiber-based line. With the recent server upgrade and this new fiber-based Internet connection, the site should now have very good performance.

Sorry for any inconvenience the downtime may have caused.

We will be upgrading our server infrastructure on Friday night, and this will likely involve some downtime as we migrate. The window for making the changes is Friday Oct 10th 21:00 CET to Saturday Oct 11th 06:00, so during this time the services may not always be available. Naturally we will try to keep the actual downtime to a minimum.

Update: The upgrade is completed and everything should be working normally. The site was offline for approx. 25 minutes during the upgrade time window. Hopefully you will all notice that the site is much more responsive now, and please contact us if you experience any problems.

We have updated our SSL certificate. If you see a message similar to:

Error validating server certificate for 'https://www.coderesort.com:443':
 - The certificate is not issued by a trusted authority. Use the
   fingerprint to validate the certificate manually!
Certificate information:
 - Hostname: *.coderesort.com
 - Valid: from Fri, 13 Feb 2009 11:58:50 GMT until Mon, 04 Jul 2011 10:58:50 GMT
 - Issuer: Equifax Secure Inc., US
 - Fingerprint: ee:79:36:14:81:be:cb:d8:90:ca:80:3c:48:0d:32:0e:49:48:c5:e2
(R)eject, accept (t)emporarily or accept (p)ermanently?

... then please accept it.

It should not be an issue with browsers, but as Subversion clients usually come without any pre-approved Certificate Authorities, all certificates must be explicitly accepted.

In recent weeks and months we have experienced an issue whereby the web projects become unresponsive - basically unable to serve your requests. During this time we have kept a very close watch to make sure we get it back online as soon as possible. Still, we know that some of you no doubt have been inconvenienced by these short downtimes.

The good news is: We have discovered and fixed the cause of the issue.

A bug in [[TOC]] wiki macro only appeared when requests where made to a page in a project that used the macro, and such a project would then permanently claim one database connection. It 'infected' a project on first view, but it did not get worse by itself. However, at random intervals pages with the macro was requested on other projects tying up new connections until at some point no further database connections could be established.

(Those that are technically inclined can read about the issue and see my fix at  http://trac-hacks.org/changeset/4366)

Finding this bug has taken much longer than we had imagined. However, it has led us to review all the central parts of the code, and fixing and reworking some parts that were not optimal. Additionally, we have updated all server software to the latest and greatest versions. The service is now in very good shape.

We can only apologize, and thank you all for being patient with us trough this period.

There seems to have been an e-mail delay today with our ISP (Broadnet.no).

We have contacted them, and the have confirmed that the there was in fact a problem, and that the problem should now be corrected. However, they warned that some further delays can still be expected as the e-mail servers catch up on the backlog of outgoing e-mails during the coming hours.

Sorry for the inconvenience, and please contact us if the delay persists longer than can be reasonably tolerated!

We have just renewed our SSL certificate, and the new certificate is operational as of now.

Depending on your browser, Subversion client, feed reader or other client accessing CodeResort services, you may receive a message along the lines of:

Error validating server certificate for 'https://www.coderesort.com:443':
 - The certificate is not issued by a trusted authority. Use the
   fingerprint to validate the certificate manually!
Certificate information:
 - Hostname: *.coderesort.com
 - Valid: from Tue, 03 Jun 2008 09:40:45 GMT until Mon, 04 Jul 2011 09:40:45 GMT
 - Issuer: Equifax Secure Inc., US
 - Fingerprint: 5a:d9:93:3e:a5:66:12:ea:8f:44:fe:04:41:f4:5c:b9:42:9e:6d:b2
(R)eject, accept (t)emporarily or accept (p)ermanently?

Please accept the new certificate permanently, and everything should work as normal.