Subversion Service Architecture Migration

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  For example, if your repository URL is, you would check:

  > server
  Default server:


  ; <<>> DiG 9.8.3-P1 <<>>
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25705
  ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

  ;    IN    A

  ;; ANSWER SECTION: 131    IN    A

  ;; Query time: 98 msec
  ;; SERVER:
  ;; WHEN: Wed May 28 12:08:35 2014
  ;; MSG SIZE  rcvd: 59

If your DNS reports that an IP address other than 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

ipconfig /flushdns

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:

  Certificate information:
   - Hostname: *
   - Valid: from Mar  7 00:00:00 2014 GMT until May 20 12:00:00 2016 GMT
   - Issuer:, 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 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 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.


  • 0
    Paul Burba


    The old style hostnames should continue to work.  Note however that we are no longer providing a SSL certificate for those domains so you will have to accept the certificate.  You might want to use the svn relocate command to point your working copies at the new URL.  If you are still having problems please contact

  • 0
    Mo Braga

    Did the SSL Certificate expired today?  I'm having "Server SSL certificate rejected".

  • 0

    Hello Mo,

    I have just verified to confirm that the SSL certificate is valid through 07/Mar/2014 to 20/May/2016. Should you experience any issues, please file a ticket to We will be happy to assist you.



Please sign in to leave a comment.