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.

GIT vs Plastic performance

Monday, July 23, 2007 Pablo Santos , 7 Comments

Performance! I’m starting to be obsessed by this word. Almost since the beginning of the project one of my main concerns has been performance: being able to run update operations faster and faster and faster.

If I remember correctly, months before our initial release I was already checking whether Plastic was faster than Perforce updating the workspace, which is one of the most common version control operations.

At a certain point in time we were able to beat Perforce (which claims to be the fast scm out there), so I was extremely happy. I knew Perforce was still faster than Plastic doing group check ins and add operations, but we were faster updating.

Later on I run a test to compare Plastic to SVN and… doing “update forced” (which means downloading again everything into our workspace) was about three times faster!! Good old days!
The last weeks I’ve been working on a big change to the “solve selector” code. What does it mean? Well, selectors are the key piece of the Plastic system, whether they are visible or not (it depends on whether users are using professional version instead of the standard one, and even then many users don’t feel like bothering with them, so prefer the “switch to branch” mechanism) they still play a core role into the Plastic system. Simply put: revisions are not “directly linked” to their containing directories (as it happens with “path space branching systems” like TFS, Perforce, Subversion and so on) but the system has to “solve” where a revision is depending on the selector.
Does it mean that the same revision of a file could be placed in different locations only changing the selector? Yes! This is exactly what it means.
The mechanism is extremely powerful, but it comes with a cost: it is not especially simple to implement. In exchange you get true rename and many other possibilities, but the system has to perform some work to calculate where each element is located.
Well, the point is that BL064 brings a whole new selector solving mechanism that greatly outperforms the old one. Now not only “update forced” is fast, but also detecting what has to be changed if someone committed a change to the branch you’re working on. The new system is much, much, much faster.

-“BL064? What are you talking about? You released Plastic 1.5 a few weeks ago… what’s that?” – I can hear some of you complaining… :-)
Well, we do use an internal build numbering (which is also available on the external releases, please take a look into the versioning info of the executables) scheme (as everybody else does, nothing new under the sun), so our last 1.5 release is actually BL063. But we’re currently using BL065 internally to support our development. So, yes, I’m afraid the enhancements I’m talking about are not yet available, please be patient.

Well, I was very happy with the new “selector system”, but then I suddenly remembered GIT… Oh! We thought we were the fastest ones in town doing updates but then I tried GIT and… well, it is stupid and ugly :-), but it is damn fast…
So I installed again GIT 1.5.2.4 on our Linux FC4 box, which has a couple of Intel(R) Xeon(TM) CPU 3.00GHz. It is already >2 years old but still runs quite fast.
$ uname -a
Linux juno 2.6.11-1.1369_FC4smp #1 SMP Thu Jun 2 23:08:39 EDT 2005 i686 i686 i386 GNU/Linux.
Then I imported one release of our own code into a git repository. I removed all the local files (except the .git subdirectory, of course!) and run “git checkout .” which is supposed to recreate all the files. It took about 20s…
Then I tried exactly the same scenario with Plastic (remember, BL065). It took about 29s. Yes, GIT is faster but… hey! Plastic server was actually installed on another box so… all the contents was downloaded through our local 100Mbps network!!!

To make it more dramatic I’d say that the test is made against our real server which is not only holding a copy of the repository (like GIT was doing) but all the whole development but… it won’t really make a big difference if the server were containing only one copy because fortunately size doesn’t affect update performance.

The bad news (for me) is that I then repeated the “git checkout . “ (after removing everything again) and it took only 8s!!! I don’t know exactly why (disk caches?) but if I run the “rm –rf *” just before running “git checkout .” it takes much longer than if I leave some time between the operations. Plastic always performed exactly the same ranging from 28 to 30 seconds, but not being affected by the remove operation being run immediately before.

“Ok, but what happens when Plastic server is installed in the same box as the client? Wouldn’t it be a fairer scenario and it would perform even better?” you may ask…
Well, I’m afraid if you want to get the answer you’ll have to wait till the next chapter… :-)
Pablo Santos
I'm the CTO and Founder at Códice.
I've been leading Plastic SCM since 2005. My passion is helping teams work better through version control.
I had the opportunity to see teams from many different industries at work while I helped them improving their version control practices.
I really enjoy teaching (I've been a University professor for 6+ years) and sharing my experience in talks and articles.
And I love simple code. You can reach me at @psluaces.

7 comentarios:

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.

Plastic keeps growing

Thursday, July 19, 2007 Pablo Santos 0 Comments

Yesterday I gathered some SLOCcount size metrics from the plastic repository.

It seems we're about to hit the 180K LOC line in a few days.
The graphic highlights the three official releases we've made 1.0 (BL047), 1.0.56 and finally 1.5 (BL063).
We're currently working on a new pack of features, some of them are already under final testing.
Pablo Santos
I'm the CTO and Founder at Códice.
I've been leading Plastic SCM since 2005. My passion is helping teams work better through version control.
I had the opportunity to see teams from many different industries at work while I helped them improving their version control practices.
I really enjoy teaching (I've been a University professor for 6+ years) and sharing my experience in talks and articles.
And I love simple code. You can reach me at @psluaces.

0 comentarios:

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.

What´s next?

Monday, July 09, 2007 mdepedro 3 Comments


We’ve just released Plastic SCM 1.5 a few days ago, our first big release since the initial 1.0 launch date back in November. We’ve tried to include customers’ requests on the latest release, making Plastic what users expect it to be, or at least that’s what we tried.


Ok, but, what’s next? What are the things you can expect in the coming releases of Plastic SCM?Well, here is a short list of things we’re about to release really, really soon (some of the features are already under testing, I mean, totally finished and just waiting for approval to be published)



  • Jira integration: one of the “already ready” features. Plastic will be fully integrated with the popular Jira defect tracking system. Both a “server side” (on Jira) and a “client side” (being able to get the associated task from Plastic) will be available.

  • CVS and SourceSafe enhanced importers: now a new import wizard will be available, helping users to migrate away from CVS or SourceSafe into Plastic. The current one is command line based, and the new one will provide a GUI too.

  • User/password security based system: most of our users integrate Plastic with a LDAP directory (both ActiveDirectory and OpenLDAP). But, on “popular demand” a new authentication system will be available: a user/password based one. It will help companies not using ActiveDirectory or OpenLDAP and who don’t want to rely on native operating system users, setting up Plastic in their environment. It will be also useful to set up internet-available servers.

  • Enhanced Eclipse integration: we’re working hard to get Plastic fully integrated with Eclipse to help Java developers in their move to Plastic. A new “check out view”, a revisited refactor support and a new toolbar will be published really soon.

  • Independent workspace and repository servers: you'll be able to set up as many rep servers as you need, which is very good for heavy load, and also as many wk servers as required.Performance: yes, performance is always an ongoing work for us...
We've made great improvements to our "solve path" system, which is the one responsible of mapping between revisions and their current locations according to the selector. Well, now detecting changes (downloading data was also quite fast) will be much, much, much faster than before...

Well, the previous ones are the features we already have finished and almost ready to be shipped, but, what are we currently working on for the coming months?



  • Trac integration

  • Subversion importer

  • Smart branching support

  • Distributed development support

  • The workflow system

  • MySQL backend

  • New GUI supporting multiple views and enhacing visualization

Feel free to post comments. :-)

3 comentarios:

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.

Plastic SCM 1.5 is out!

Thursday, July 05, 2007 Pablo Santos 2 Comments

We are very happy to announce the new Plastic SCM 1.5 release!

Plastic SCM 1.5 introduces a number of new features and enhancements over the previous version 1.0.

The new release is a step ahead in the product evolution. The most important features on the new Plastic SCM release are:

  • Query System: the new Plastic SCM release introduces the new query system. The query system is the mechanism provided by Plastic to search data inside the different repositories in a customizable way.
  • New Security System: new capabilities allow the definition of customized access rights to directory trees (and still being able to customize the repository and branch hierarchy) greatly simplifying the security management. A new type of special user is introduced, the owner, allowing administrators and SCM managers to set special permissions to the objects’ creators.
  • Branch explorer: it is one of the most anticipated features in the new Plastic SCM release. Now developers will be able to visualize the whole project evolution using this new capability, which is a new step ahead, together with the 3D version tree, in SCM data representation.
  • Merge system improvements: the merge system has been greatly improved for release 1.5. The Plastic SCM merge support was already one of the most powerful merge system available, implementing features like merge tracking, true rename (required for refactoring support) and an optimized contributor calculation. During the last months the development team has worked in merge performance and implementing an even better renaming support.
  • SQL Server support: Plastic SCM is a new generation system and hence uses a RDBMS as data backend. The backend can be configured by the user.The first Plastic SCM official release only implemented Firebird (http://www.firebirdsql.org) as data backend, which is a strong and fast open source database. Plastic SCM will continue including Firebird as recommended database but SQL Server (2005 and higher) support has been introduced to adapt to customers’ current IT options.
  • PowerBuilder integration: Plastic SCM implements a SCC compatible plugin which provides full Visual Studio integration. A number of IDE are compatible with SCC and the 1.5 release has been specifically tuned to include PowerBuilder as one of the supported platforms.
  • CruiseControl support: the release 1.5 is integrated with CruiseControl 2.7, allowing users to automate build and release tasks both with .NET and Java.
  • JDeveloper plugin: there is a new JDeveloper plugin. Now both JDeveloper and Eclipse developers can benefit from a full featured integration which will boost their productivity working together with Plastic.
  • Enhanced Linux installer: release 1.5 introduces an enhanced Linux based installer. Now installing and setting up Plastic will be much easier on systems like Ubuntu, Suse and Fedora.

Enjoy!

Codice Software team!

Pablo Santos
I'm the CTO and Founder at Códice.
I've been leading Plastic SCM since 2005. My passion is helping teams work better through version control.
I had the opportunity to see teams from many different industries at work while I helped them improving their version control practices.
I really enjoy teaching (I've been a University professor for 6+ years) and sharing my experience in talks and articles.
And I love simple code. You can reach me at @psluaces.

2 comentarios: