Code repositories and file downloads from this site are available again following an earlier network switch failure. We apologise for any inconvenience arising from this outage.
SoundSoftware services were unavailable overnight following a failure of the cooling system at the hosting site. Services were shut down cleanly in order to avoid overheating, but there was unfortunately no opportunity to notify users beforehand. Service has been restored this morning. Our apologies for this outage.
The SoundSoftware code site uses Mercurial as its native version control system. To make it easier to get on with people and systems that use Git instead, we've just added a simple read-only Git interface for the public projects on the site.
Each public project on this site now has a Git clone URL, that is the same as its Mercurial clone URL but with "hg" replaced by "git".
For example, given a public project named "myproject", the Mercurial repository has always been (and continues to be) available via a command like
$ hg clone https://code.soundsoftware.ac.uk/hg/myproject
And now the same repository, with all its history and branches, is now available via Git using
$ git clone https://code.soundsoftware.ac.uk/git/myproject
This is a read-only mirror: you can't push to this URL, it is simply silently updated to reflect the contents of the project's Mercurial repository. That update happens periodically so there may be a delay of up to an hour before each commit pushed to the Mercurial repo becomes available via Git. (We may reduce or eliminate this delay later on.)
The feature is designed as a repository mirror, not an endpoint for active everyday use. There is currently no access control for this service, so only public projects are made available in this way.
An example with a real project:
$ git clone https://code.soundsoftware.ac.uk/git/cepstral-pitchtracker
1. You have a published software project (not one undergoing rapid development) and you want to publicise it to users who prefer Git (and who are not project members who would need commit access).
2. You have started a project on the SoundSoftware site and you decide later that you want to move it to, or mirror it on, Github. You can do that like this:
# create a bare git repository (not a working copy) containing # the entire history and all branches: $ git clone --mirror https://code.soundsoftware.ac.uk/git/myproject $ cd myproject.git # ... and mirror it to a Github repo: $ git push --mirror --firstname.lastname@example.org:myself/myproject.git
(Note that you can already do this the other way around, using the SoundSoftware site to mirror a project whose primary hosting is at Github. See the "Track an external repository" option in your project's Settings -> Repositories for details.)
- The Git clone URL is not yet displayed in the project's repository page. We're still considering how this information should be shown, given that the Git repo is a mirror with some limitations rather than a "first-class" copy.
- The Git clone URL can only be used with a Git client; you can't browse to it in a web browser.
- Mercurial subrepositories are not converted, so if you clone a repo for a project that uses subrepos, you will get only the containing repository without any of the subrepos in it.
Due to essential router maintenance work, this service will be unavailable for up to two hours on the morning of Thursday 27th August 2015.
Services are now fully available again, following disruption caused by a power failure at the hosting site.
At around 15:00 BST yesterday the three-phase power supply to the hosting site failed, causing a loss of cooling and network connectivity. The servers were cleanly shut down before the supply company was able to attend at around 20:00 and services finally restarted this morning. The timing was unfortunate in terms of admin availability, so it took us longer to restore access than it should have, and we did not anticipate the length of the resulting outage. Our apologies for any inconvenience that this may have caused.
As a consequence of construction work at the hosting site, the SoundSoftware code site and its associated resources may be unavailable for some hours during the day on Saturday 28th February. Our apologies for the short notice.
A networking configuration change made earlier in this week appears to have successfully resolved the problem pushing large changesets and attaching files to projects on this repository. If you have any further problems in this area, please let us know!
We're aware that some users have been experiencing problems pushing large changesets to the repository, and attaching files to project pages. We believe we have found the cause of this and are working to resolve it.
Please accept our apologies for this morning's downtime to this site (and to our project site). Both were inaccessible for some hours, after an interruption to the server room power supply knocked out the cooling for our servers. We had to wait for the power company to respond before we could bring our services back up. As far as we can tell, this should be an isolated incident and no data was at risk.
The SSL certificate for this site has just been updated. You shouldn't notice any difference when simply browsing through https, but if you have stored the host fingerprint in your Mercurial configuration, you'll need to update it.
The new certificate has fingerprint
Background, or, Why would I need to do this?¶
When you use Mercurial to pull from an https URL that is unknown to the hg client, Mercurial will complain about it with a warning like this:
warning: code.soundsoftware.ac.uk certificate with fingerprint 0d:ff:f3:46:55:7a
:be:4c:00:4c:82:9b:cf:71:13:03:b2:08:25:4d not verified (check hostfingerprints
or web.cacerts config setting)
You can avoid this warning by storing the certificate fingerprint in your Mercurial configuration.
To do so, add the following lines to the
.hgrc file in your home directory:
Then Mercurial will check the certificate and continue silently if it is correct, but will refuse to continue at all if the certificate doesn't match (because that could indicate a serious security problem).
But this does mean that if the host key ever changes legitimately (as it just has), you will need to update the configuration by hand. The lines above show the new fingerprint, so if you have the old one stored, you should change it to that.
Also available in: Atom