Who we are

We are the developers of Plastic SCM, a full version control stack (not a Git variant). We work on the strongest branching and merging you can find, and a core that doesn't cringe with huge binaries and repos. We also develop the GUIs, mergetools and everything needed to give you the full version control stack.

If you want to give it a try, download it from here.

We also code SemanticMerge, and the gmaster Git client.

Powered by Firebird

Sunday, December 17, 2006 Dave 3 Comments

It's been already a long time, but I still remember when we decided we would use an standard database backend for Plastic SCM. At the moment it really looked like a risky decission (well, nowadays more and more SCMs are moving towards this option, so it seems we are not wrong... I will be able to sleep better from now on ;-P ), but there were many advantages like:
- We didn't have to care about the data storage's safety properties. This was really a huge step forward: using a RDBMS you get basic ACID properties... Nice for a version control system.
- Full transaction support. Today every serious version control system will provide "atomic commit operations". Well, using a RDBMS, again, you get it for free (ok, there is a nice layer on top of it, but this is another story...)

So, which database should we use? We didn't have a big amount of code yet, we were making some tests, prototipes and so on. And then we decided Firebird would be the way to go. Why? Well, we had some previous experience with Interbase (I still remember comparing its full serializable support against SQL 6.5 back at university) and later on with Firebird on Linux too.
We tried the embedded option and... well, it really rocks! A full featured database backend and you can redistribute it just copying some dlls. Simply put: great! Indeed, the greatest one out there.
So then we decided Firebird would be an important part of the product. And I can tell you this is one of the decissions we never regret. BTW we wanted to have a full portable data layer (in terms of DB independency), so we also tried with Postgres (specially on Linux and Solaris) and later on with SQL Server. Results? Firebird is the easiest to deploy and has a very good performance ratio (and we always find ways to tune it even further), Postgres is a bit faster in some operations but extremely slow dealing with BLOB data and SQL Server is faster but much harder to deploy. So we are proud to tell that Firebird is a center piece of Plastic SCM. In fact we are about to release the Linux based version and... finally we moved it away from Postgres to Firebird 2.0.
Thanks to the Firebird team!


  1. Hi! Thanks for posting this! For sure this is the kind of public report that Firebird needs to become more "visible" inside the database community.

    BTW, have you become a member of the Firebird Foundation yet?


  2. Thanks Carlos!

    We would love to be members of the Foundation. What should we do?