|
Plastic SCM |
A system like CVS is supplying the basic features of a SCM but it does not offer the ones that make a difference on improving your productivity and control.The following table compares Plastic SCM and CVS focusing on the differences on security, branching and merging and other high-end features.
| 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.
|