Announcing Plastic SCM 2.9

Sunday, February 28, 2010 0 Comments

Plastic SCM turns 2.9 and it’s ready to download from our site: www.plasticscm.com.

It comes with a bunch of new features and also gets faster specially under heavy load.
Here are some of the new things we’ve included:

  • Oracle support: yes! We’ve added Oracle to the list of our supported database backends. It joins the group integrated by MySql, SqlServer and Firebird. Oracle has been requested several times by corporate users and it brings one of the strongest RDMBs on the market to Plastic deployments. Performance, stability and scalability are the main goals for it, and it works with Windows, Mac OS X and Linux servers.

  • Pulse continuous integration is now supported: we built a plug-in for Zububi’s continuous integration product. It expands the number of supported build solutions we have, together with CruiseControl and FinalBuilder, although others like Hudson (and any product out there being able to run a couple of ‘cm’ commands) can work with Plastic too.

  • Proxy server: now it’s possible to set up cache servers to reduce network usage while connected to a central server. The proxy simply caches data on demand and avoid re-downloading it again, saving precious network seconds. Note: you know Plastic can work on both distributed and centralized modes, so obviously this feature is useful for people connecting to remote servers and not that much for distributed developers or teams since they already have their data quite close.

  • Sparse tree and cloaking support: now it is possible to download only parts of a repository (ok, it was also doable with selectors, but this way is probably easier) and avoid updating certain files or entire trees by using a cloaked.conf file specifying rules to cloak elements. It’s very useful specially to speed up certain operations (like update) on huge trees and hence avoiding walking through certain parts you know you’re not interested on receiving changes. For advanced users only.

  • Replication memory footprint has been greatly reduced. Memory usage during replication has been reduced, making it faster and much more predictable than before. Now you can replicate an entire repository and the server won’t even notice it in terms of memory footprint!

  • Workspace server is gone! Yes, as you read it, we’ve removed the workspace server component from the picture. Well, in fact, what we’ve done is move it into the client, so performance is dramatically increased. What does it mean? Watch your newly created workspaces and you’ll see a new directory (hidden) named .plastic, it contains workspace information like the selector and the tree with the information about your working copy. This information used to live on the server side, but it has been moved to the client. It dramatically speeds up the system on many scenarios and reduces network usage, which was probably not noticeable on LANs but makes a huge difference for users working against a central server using a VPN. Important note: when you upgrade from Plastic 2.8 to 2.9 the system will recalculate your workspaces in order to move to the new format. It will only happen once and it will be pretty fast (your workspace content won’t be modified, it’s all just about metadata). If you’re using the graphical client you’ll see something like the following:

  • Sharable workspaces: with the modifications made on the workspace it’s now possible to share workspaces: you can place a workspace on a shared network drive or a NFS directory and more than one user can access to it, update it and so on from different machines. Previously it was not doable with Plastic unless you registered the workspace on several locations, and even then it could end up with race conditions. It has been solved. Use it with care, I mean, sharing a workspace can be good for release building purposes but obviously the whole point of having a SCM is being able to manage your own private working copy!

  • Changeset walking: one of my favorites! You can walk branches changeset by changeset, reading the story they’ve to tell. I’ll post more about it later but think about it: on your own feature branch you’re free to do as many commits as you won’t before hitting the mainline, but it doesn’t prevent you to self document your changes by committing often and with meaningful comments and changes. Let me elaborate a little bit more: suppose you’ve to do a big refactor, you make a whole bunch of changes, then if you review the whole thing at the end, it will be hard to follow, but if you describe every individual modification (considering it as a logical change, potentially involving several files) in a commit, this tool will let you review what you’ve done later, very, very easily.



  • Branch explorer enhancements: new search functionality landing on branch explorer, together with active information about merge links (click on one and it will tell you where it is coming from) and the long awaited visibility editor.





    Well, and that’s basically it, together with a huge number of small tweaks here and there. We run load tests weekly on a 100 nodes cluster, and under really heavy load Plastic 2.9 is about 30% faster than its predecessor. Not bad! Remember we were already 10 times faster than SVN with 2.8 and make the math.

    And the best thing: Plastic grows but stays easy to use and easy to install. Take a look at the following screencast: I install a Plastic server in less than 45 seconds!! And I make an initial code import after that (the first steps you’d probably do during an evaluation) during the next minute. Easy! Take a look at the latest TFS 2010 and tell me if you can set up the whole slow monster in 45 seconds!! :)



    Enjoy.
  • 0 comentarios: