In March of 2014 Collabnet launched a new, more reliable Subversion service architecture for Cloudforge. Since March, all new Cloudforge accounts have used this new architecture. Existing accounts however, continued to use the previous service. In June of 2014 we will begin the process of migrating these existing accounts to the new architecture. The following FAQ will help you understand what this means for you if you are using Subversion with Cloudforge:
"What's the benefit for me?"
An even more stable and reliable Subversion service.
"When will my organization be migrated?"
The migration will be performed on a rolling basis starting in June of 2014. The owner of your organization will receive an email notification when the migration begins. The migration process should take a few hours at most. For domains with few and/or small repositories this process may be significantly quicker. For very large and/or numerous repositories however, the migration may require more time.
"How will the migration affect me?"
During the migration there will be a brief window during which your Subversion repositories will be read-only as we switch to the new architecture. All other aspects of Cloudforge will remain fully functional.
"What do I need to do?"
You don't need to take any action until the migration is finished. When the migration is completed, your organization owner will receive an email notification to this effect. At that point you can continue making commits to your repositories. There are a few points to be aware of however:
a) The IP address of your Subversion server will change once the migration is completed. While we will immediately update our DNS server to reflect the new IP address, it is possible that your ISP's DNS server, your networks's routers, or even your own workstation will cache the previous value for a short period of time. This may temporarily prevent you from making commits to your repositories even after the migration is completed.
For example, let's assume you have received an email notification that your migration is complete, but when you try to commit a change to your repository you see an error similar to this:
svn: E165001: Commit failed (details follow):
svn: E165001: Commit blocked by start-commit hook (exit code 255) with output:
Organization is being migrated; repository is read-only at this time (ref svn11a:JJiMP5xFbzmSktf4)
In this occurs, you should use the 'nslookup' or 'dig' commands and check that the new IP address of your Subversion server is 188.8.131.52. For example, if your repository URL is https://myorgname.svn.cloudforge.com/projectfoo, you would check:
> server myorgname.svn.cloudforge.com
Default server: myorgname.svn.cloudforge.com
; <<>> DiG 9.8.3-P1 <<>> myorgname.svn.cloudforge.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25705
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;myorgname.svn.cloudforge.com. IN A
;; ANSWER SECTION:
myorgname.svn.cloudforge.com. 131 IN A 184.108.40.206
;; Query time: 98 msec
;; SERVER: 220.127.116.11#53(18.104.22.168)
;; WHEN: Wed May 28 12:08:35 2014
;; MSG SIZE rcvd: 59
If your DNS reports that an IP address other than 22.214.171.124 then you will find that your commits are still blocked. You have a few options in this case:
1) Wait - You can simply wait until the DNS caches expire and update to the new IP address. This might only take a matter of minutes, but might take significantly longer.
2) Flush your DNS cache - Depending on what DNS you are using, you may be able to flush its cache manually. We can't cover all the cases here obviously, but for example, if you are using Google's public DNS, you can use Google's flush cache tool to refresh the DNS's cache for a particular domain.
3) Flush your local DNS cache - Even if nslookup or dig is reporting that your Subversion server's IP address is updated, you may need to flush your workstation's local DNS cache before you can commit. How to do this varies by operating system, but some of the common ways include:
i) Windows XP/Vista/7/8
ii) OSX 10.7 or newer
sudo killall -HUP mDNSResponder
iii) OSX 10.6 or older
sudo dscacheutil -flushcache
iv) Linux - Many Linux distributions have no local DNS cache installed by default. Those that do frequently use NSCD (Name Service Cache Daemon). If you are using NSCD this command will clear the local cache:
nscd -i hosts
Note: Your repository URLs will not change, so there is no need to 'svn relocate' your Subversion working copies.
b) We will leave your old repository in a read-only state so that it will continue to service read requests until the old servers are decommissioned. Depending on when your migration takes place this decommissioning may occur several weeks or only a few days after your migration is complete, but remember, these old servers are only a convenience, you want to use the new server!
c) Be aware that the SSL certificate for your Subversion server will also change:
- Hostname: *.svn.cloudforge.com
- Valid: from Mar 7 00:00:00 2014 GMT until May 20 12:00:00 2016 GMT
- Issuer: www.digicert.com, DigiCert Inc, US
- Fingerprint: 2F:F0:D8:CE:26:6F:50:B2:D3:41:26:6E:47:1B:11:A4:3B:5B:2E:AA
d) Because of changes to the Apache authentication realm, you will need to re-enter your commit credentials on your first post-migration commit.
"Wait, my repository points to an old-style ORGNAME.svn.cvsdude.com domain, will that still work?"
Partially: Old-style domains will resolve to the new IP address and you can continue to use these, but we will no longer provide a SSL certificate for these domains. So you will have to accept the new svn.cloudforge.com certificate. You may want to use the 'svn relocate' command to point your working copies to the new domain, you can find details of how to do this here.
"What happened to my On Demand Backups/Snapshots?"
Self-serve on demand backups and data snapshots are no longer provided for the Subversion service. Instead we recommend that you use Subversion's svnsync feature to obtain copies of your repository data.
"Can I schedule my migration for a convenient time?"
Unfortunately this is not possible. Keep in mind that your repositories will remain accessible throughout the entire process and commits will be blocked only for a short time while we synchronize the repositories.
"I never saw a notification about this migration, is something wrong?"
Only the organization owners will receive notifications regarding the migration status. Also, if your account was created after March 5th, you organization is already using the new service and does not need to be migrated.