Configuring Plastic SCM Database Backend

Introduction

Plastic SCM is a new generation version control tool. It seems to be entirely written in .NET/Mono and it provides many interesting features for both Linux and Windows developers (needless to say how good it is for multiplatform environments).

But today I won't be talking about version control issues but how to configure the Plastic database backends.

Plastic stores all the versioned data in a standard database backend, which is quite interesting because nowadays no one wants to have its important business data stored in some sort of awkward specific-purpose storage... I mean, would your customers allow you to store their business application's data into a specially designed file based storage or would they ask you to use MySQL or SQL Server or something else? Ok, think on SVN, CVS, SourceSafe... yes, they might be open but, can you really take a look into the data with standard tools? Can you select the backend more suitable to your specific needs?

Default Database Configuration

Well, when you first install Plastic, it will be using a Firebird database backend. If you're running on Windows, by default it will use the embedded Firebird server. Once the server is started, you'll see three database files created: check for the *.fdb on the server's directory and check how many you have. You'll always have one repositories.plastic.fdb which contains information about all the created repostiories, workspaces.firebird.fdb containing information about the available workspaces, and finally one rep_xxx.plastic.fdb for each repository you have.

You could take a look into the data with something like "ibmanager", but you'd first have to stop the Plastic server, otherwise the default Firebird embedded server will keep the files locked.

Customizing the Database Backend

I mentioned the database files are created by default on the server's installation directory. Well, this can be enough for a test run, but most often than not, you'll like to keep those files on a special purpose directory in order to ease backups. How would you do that?

Create a db.conf file in the server's directory (where loader.exe resides, or plasticd.exe if you're running preview 2.0 or higher) with the following contents:

Note the file specifies three things: a provider type (more on this later), a connection string (.NET or Java developers will be quite familiar with it) and a database path. If you leave a param empty, the default one will be used.

Improving Performance

If you've ever used Firebird, you'll know server's performance is actually better than embedded's one. So, let's try to change it to make Plastic server perform better.

The following figure shows how to set up an external Firebird server connection so that the Plastic server will use it instead of the embedded's one. Note the ServerType is now 0 (1 is used to set up the embedded one).

The backend configuration is quite flexible which is very good specially if you're concerned with scalability or performance. What if you want to deploy the plastic server in an internal network which already has a powerful database server? You could run the Plastic server on a computer and the database server on a different one, which will normally boost performance. The following figure depicts the scenario.

And, how would you set it up. Check the following db.conf and note how a server, port and some other Firebird parameters can be easily tuned.

Enter SQL Server

One of the least known features of the plastic server is that it is not constrained to a Firebird database, it can use SQL Server too. Plastic can use SQL Server (2005 or higher, this is very important to note because it needs to set some transaction parameter only available on 2005 and higher) which is better for companies already using the Microsoft's DB software.

Setting up a SQL Server backend is also done by changing the db.conf file. Take a look at the following figure to learn how to set it up.

It is important to note that switching database backends won't migrate data from one DB to the new one, but it will just tell plastic to start working against the new backend. If you want to migrate the old data, you should use some standard application to move data between the desired backends or contact plastic's support.

Conclusion

Being able to change the backend where your versioned files reside gives you more flexibility and the ability to design a better SCM infrastructure.

History

• 20^th January, 2008: Initial post