After several months of beta availability for Workspace, we're ready for business! Along with that change, we decided we needed something a bit more flashy, and Firefly is born.

For existing users, we'll be contacting you soon with more details about your accounts, but I thought I'd say something about some technical aspects of your usage of Firefly.

For Subversion and Mercurial users, your existing checkouts should continue working just fine against the old workspace domains. You should update your local repositories though, to use the new urls. For Subversion, you can change to using svn.firefly.activestate.com with the "svn switch --relocate" command. For Mercurial, use hg.firefly.activestate.com with hg pull and then hg up.

We'll be posting more information over the next couple days, and as always are available from our support forums.

Recent changes in Workspace infrastructure have had some unintended effects for users with project repositories checked out before Sept. 28th.

Workspace projects used to have URLs that looked like this:

 http://workspace.activestate.com/projects/sandbox

The SVN repository URLs of these projects looked like this:

 http://workspace.activestate.com/svn/sandbox

Now, projects have "namespaced" URLs to allow different users to have projects with the same name (think "MyProject", "test", "Website" etc.). The new project URLs look like this:

 http://workspace.activestate.com/troyt/sandbox/

... with associated SVN URLs of:

 http://svn.workspace.activestate.com/troyt/sandbox/

We had intended that the URLs of projects created before this change would continue to work normally and interchangeably with the new project locations. In fact this did work until recent changes to how we load balance Workspace broke these redirects. We were faced with a conundrum: without the load balancer, we can't scale Workspace effectively; with it, we can't handle the old SVN URLs.

Unfortunately, this means users of projects created before Sept. 28th will have to switch to using the new URLs.

Fortunately, this isn't that difficult. It should be as easy as running the 'svn switch' command. For example, for a checkout of the Sandbox project shown above, you would 'cd' to the root directory of your local working copy and run:

  $ svn switch --relocate http://workspace.activestate.com/svn/sandbox http://svn.workspace.activestate.com/troyt/sandbox

This will update the local working copy to mirror the new URL. Subsequent svn commands should work normally. The checkout command shown on the project's "Source->Checkout" page displays the correct, new URL.

We'd like to apologize to those users who have run into this problem, and reassure everyone that we will do everything we can to minimize disruptions like this in future. We feel that the changes have helped make Workspace faster, more robust and more stable than it was when we started the Beta, and we hope to continue this trend.

Workspace has just had a major update which adds  Mercurial support, a feature lots of users have been asking for. To get the details of what's new and how it was implemented, I asked Shane Caraveo some questions about this, and here's what he said:

The Workspace project URLs have had a bit of a shakeup, why was that necessary?

One of the first issues users brought to us was the inability to create a project called 'test'. This was because someone else had already created one. That is certainly a usability issue, but also, admittedly, a little lame. Workspace now allows for different users to have projects with the same name. In order to allow that, we had to change the URL structure to have the projects under the username, rather than all under a single URL path. We also moved repositories onto their own sub-domain (i.e. svn.workspace.activestate.com/...).

There have been some significant performance improvements. Can you tell us about those?

In the initial release of Workspace, we had a number of performance issues. Over the summer we worked hard to address those issues and now have a system that performs and scales well. It will never reach Google-speed, but I doubt we'll achieve the gazillions of requests that they have!

I know you've answered this in the Workspace forums, but I'll ask it again for those that missed it. Why Mercurial and not Git? Was the Python team's recent decision to use it part of this decision?

We have not ruled out supporting Git. It is one of the major source control systems and it has a very large following. We choose to implement Mercurial support first because it fits with our infrastructure better than Git does, and we could provide that support with a lower development overhead. Having the Python team using Mercurial is a positive for Mercurial, but didn't have any affect on our decision to provide Mercurial first.

What cool things can you do with Mercurial that you can't do with SVN?

I'm personally no Mercurial expert. For me, the primary benefit of Mercurial, and Git, is the distributed nature of the system. If you're not familiar with distributed version control, you can think of it simply as having a local repository that you can submit your work to, then occasionally merging it into the central repository. There are all kinds of benefits to this. One I personally like is being able to work with a repository when I do not have internet access. There's a nice  article on this at betterexplained.com.

People keep asking me when Workspace will be out of Beta. Can you tell us that?

We would love to have people paying for Workspace! There's a very good reason to be in Beta, which is we want to gather as much feedback as we can, and we want to be sure the system is highly reliable and performs well before turning it into a for-pay service.

What's next for Workspace? Any new features on the horizon?

Workspace, as it is now, is focused on individual developers and small projects. Our focus going forward will be providing a service with features for organizations like ourselves. That is not as big of a shift as it may sound, we're using Workspace today for several projects. However, there is functionality that larger organizations and projects can benefit from, and we want to provide that.

Workspace, in addition to all of it's other amazing features, has a fantastic blog engine. We've decided to put this to good use and post Workspace-related news from ActiveState here.