| Feature |
CVS |
Plastic SCM |
| Security |
CVS is not able to give different permissions to the repository objects and it does not provide integration with authentication methods. |
Plastic SCM implements ACLs for each one of the elements defined in the system, so you are free to decide your security policy without any restriction.
Furthermore, Plastic provides different authentication options ranging from its own user/password system to LDAP or ActiveDirectory integration. |
| Distributed development |
CVS does not provide any solution for remote development. |
Plastic SCM supports geographically distributed development environment through its TCP/IP based structure, allowing companies to choose between the distributed method, multisite or off-line.
The system is controlled through a single command that allows branches to be replicated in a fast and simple manner. |
| Deleted and moved items |
When CVS deletes an item, it's completely removed from the repository, including all previous versions. Moved or renamed files are kept on the last place they were moved, so it is not possible to reproduce a previous source tree in case the user needs to go back. |
One of Plastic SCM strengths is the ability to seamlessly manage moves / renames / deletes of any item in the source tree, by fully versioning directories the same way that files are. This is specially useful for refactor operations, where an IDE moves a file from one folder to another and Plastic automatically handles the operation. Deleted items can be easily recovered through the "Removed items" view. |
| Atomic check ins |
CVS does not have an atomic change mechanism and cannot group changes to related files, if some of the files involved in a check-in operation are rejected, the codebase is left in an inconsistent state. |
Plastic SCM groups every check-in done on a "group of changes", which is given a specific number. This way it is very easy to identify which changes made up a certain feature. Going even further, every change related to a specific task can be put together on a branch, as creating branches and merging them with others is a very automated and efficient process with Plastic. |
| Branching and merging |
In CVS creating a new branch implies replicating all the metadata on the new file, which is totally inefficient and it makes it very difficult to see what was changed on a certain branch; and it does not keep a history of integrations, users must track them manually and there is no automated conflict resolution available when merging files |
Plastic SCM has created a solid core for managing branches, especially for merging; and not just files but also directories.
These operations have been completely redesign from scratch and are totally different from CVS operations. This is why Plastic recommends using branching in order to implement parallel development methods such as "branch per task" or "branch per developer". |
| Visualization |
CVS does not provide any visualization tools apart from the GUI. |
Plastic SCM offers a wide variety of visualization tools to increase performance and provide a clearer view of the project at any stage: 3D version tree, branch explorer, statistic tool, code review tool, three way merge tool, etc. |
| Scalability |
CVS does not provide multiserve support and furthermore, its repositories can only be stored on its database backend. |
Plastic SCM is designed to grow with your company; it provides multiserve support which allows any sized company to balance their load into as many servers as required, and it goes further: through configurable database backends companies can choose from Firebird, SQLServer or MySQL depending on their needs. |
