Plastic SCM
From Wikipedia, the free encyclopedia
Plastic SCM is a commercial proprietary SCM system. It is developed by Codice Software, Inc. and was founded in 2006 by Pablo Santos and David Suárez. Plastic SCM provides high-end functionalities at an affordable cost.
Contents |
[edit] Plastic SCM features
[edit] Multiplatform support
Plastic SCM is built on top of .NET technology, so it works great in any Windows version including W2K, W2003, XP and Vista.
But is also fully compatible with Mono, so it can be used on Linux, MacOS and Solaris too.
[edit] Advanced branching model
First time you see a SCM system you just get the idea of checking things in our out. This is the first advantage over developing without safety net, without a version control that protects your development from losing code.
But there are other advantages that a SCM can provide to developers like allowing parallel development, management of different product releases or isolating changes, among others.
Many of these advantages have something in common: branches.
Branching in PlasticSCM is not an added feature, is something present from the beginning. Branching adds an extra dimension to the whole project tree.
In order to create a new revision of an item in a different branch with PlasticSCM, you don't actually need to branch its parent directory, you are just telling to the system you want to branch the item, why doing something else?
Branching patterns are explained in detail in the book Software Configuration Management Patterns, by Steve Berczuk and Brad Appleton and also in the web.
[edit] 3D Version trees
Version tree showing the history of a given file. You can appreciate merge links (the green arrows), showing merge relationships between revisions.
More information like applied labels to a revision are also displayed.
A bigger version tree shows the more complicated life of another item inside our repository. Multiple merges from different branches are shown, and many applied labels.
[edit] Full directory versioning
Full directory versioning means that the system will manage directories the same way it handles files. They are first class participants, and their data is the files they contain.
What this means for your team? Simply put: you can easily manage file or directory move and rename. You are not constrained by your SCM's restrictions, you are free to fully reorganize your project structure at any moment in time. This is quite often the case when a project reaches a few months of development. Components have grown, and files need to me moved around to accommodate a wider structure.
Just have a look at other SCM products (CVS, Subversion or Perforce) to see that most of the time this kind of job becomes quite hard.
Have a look at the video describing the following scenario:
- One file is under the source control in the main development branch.
- Developer one creates a branch and modifies the file.
- Developer two renames the file on the main branch.
- Developer one integrates his work to main branch and: the file gets renamed but including his changes.
[edit] Track of merge operations
Branching is one of the core Plastic SCM capabilities. To perform really powerful branching, a good merging mechanism is required. And merge tracking is key in the process.
Each time a merge is done, a link is created between the participating revisions. The link is not only important to illustrate the process (to be displayed on a version tree), but used internally by Plastic in the following merge operations.
Placing the right merge links and using them correctly is an extremelly important feature for a serious SCM system. In fact, many low cost systems fail doing that. What is the problem if that happens? Subsequent merges can be broken or innecesary merge operations will happen, making the integration process harder than needed. Let's think about a maintenance branch which have to be repeteadly merged with a main feature branch (to include all the maintenance work on the main development line, for instance). If the merge tracking is not correctly handled, keeping the development line up to date will be much harder than needed.
Plastic SCM excels doing merging, being really useful to implement different development strategies with confidence.
[edit] Owned differences and merge tools
- Code differences: Classical code file differences have been enhanced aplying syntax highlight. This makes the code easier to read and follow. Soft gradients and carefully chosen color schemes to display differences also contribute to an overall more comfortable experience.
- Image differences. Supporting two modes, side by side or blended, where both images are blended together making it very easy to spot differences. A slide bar controls the level of transparency applied to the images.
- Code merge: The 3-way merge is always a complicated process. We applied the same visualization technology previously used for differences, this time a step beyond. Our merge algorithms are highly optimized to resolve automatically as many conflicts as possible, and even for those not automatic, try to suggest the best possible solution before hand.
- Binary merge: When no text-file resolution is possible, conflictive merges are solved by the binary merge tool, able to display images and Microsoft Office contents so the user can choose the right version to merge.
- Directory dff and merge: As directories are fully versioned in PlasticSCM, there are also specific graphic interfaces for them.
[edit] ACL based security
If yours is an open environment, then probably security is not a big concern. When a development group becomes a team setting barriers with security is not a good idea. Still, there are always certain assets to protect, depending on the different people accessing your system.
There are also many projects in which having such an open set up is not a good idea: personnel mobility, big amount of developers, junior staff, among others, require a more secured SCM deployment.
That's why in PlasticSCM security mechanism allows a full customization. Everything is possible, from disabling security or giving default access, to fine grane tunning on a per object basis.
[edit] Workflow system
Plastic SCM provides an out-of-the-box set of pre-configured workflows that allow any organization to trace development efforts from a single requirement, to the tests that validate it in a given release. Traceability is achieved looking the tasks that implemented the requirements, the releases on which those tasks were integrated, and the tests results for those releases.
[edit] Customizable database backend
The Plastic SCM server transparently handles versioning. It manages both revision's data and metadata in a safe and efficient way. But, where is the data actually stored?
Many version control systems rely on their in-house data management implementation. Plastic SCM uses relational database management systems for that purpose. Relying on those systems has many benefits like having fully transacted operations (ensuring data integrity), performance or well defined backup and restore mechanism.
Plastic SCM can be configured to work with Firebird, Postgresql or SQL Server database backends, each of them having different features and benefits.
Being able to work with different database backends is not only good as added value for clients, it is good for software design. Our datalayer is currently ready to support other database systems like Oracle or MySQL.
