April 18, 2013 / by Daniel Huchthausen / In Technology

Version Control Part 1: SCM and the SCM-Manager

+++This post was migrated from our former blog about SCM-Manager Universe. Therefore, the design is slightly different and some information might not be 100% applicable to Cloudogu EcoSystem. So don't be alarmed; enjoy reading.+++

Nowadays distributed source code management is a must-have tool for every developer and a large number of different implementations compete for attention. So getting started is a complex task. To make the start more easy we want to show you today the development of source code management from centralized to distributed systems and the on top tool SCM-Manager. In following articles we will familiarize you with the different version control systems (VCS) in more depth.

What is Source Code Management?

Source code management originates from revision control, which is the management of changes for e.g. books or source code. Usually revisions are identified by a revision number. They are also associated with a timestamp and a sign of the originator. Due to revision control it is possible to work on one document with multiple users. A user can create a local working copy” by checking out the document. By that a developer branch is created. Changes that are made to the working copy can be merged back to the “line of development” by committing or checking in the document again. Source code is stored in so called repositories. If several people are working on one document simultaniously the changes are checked in chronologically.

Source code management tools are specialized in revision control for software development. In general two different kinds of revision control can be distinguished: centralized and distributed systems.

Centralized Revision Control Systems

Centralized revision control systems are storing all source code in one, central location. A developer checks out source code, makes changes and commits them. By committing the changes they get incorporated in the central location. This approach guarantees that the source code can always be found in one place. Therefore developers don´t have to keep many different copies of the source code on their local drives. If you want to save changes to a repository by committing, you have to be connected to the server. Common centralized version control systems are CVS and Subversion (SVN).

Distributed Revision Control Systems

Distributed revision control systems came up in 2005. The main difference to centralized systems is, that they do not necessarily store all the revisions on one central server. Every developer clones a copy of a repository and has the full history of the project on his hard drive. This method results in a bigger amount of required disk space, but since that is so cheap nowadays, this is not a problem. A developer can “pull” the latest versions of repositories to his hard drive, make changes and “push” them to other developers. Common distributed revision control systems are Git and Mercurial. If you want to know more about these two systems, you will soon find a comparison of those two systems in this blog.

State of the Art in CVS’s

Today CVCS´s (centralized version control systems) are considered old fashioned and DVCS’s (distributed version control systems) are the future. All DVCS’s have features superior to those of previous centralized solutions but none sticks out as Subversion did in the previous generation. Each DVCS is designed to serve a particular purpose, e.g. to support different styles of development or programmers habits. The question, which system suites best ones particular requirements, is often a matter of personal choice. Let’s focus on DVCS’s general advantages over CVS´s.

  • Committing changes to the local copy is very fast, because only the local hard drive, instead of a remote server, needs to be accessed.
  • Commits can be done without anyone else noticing it. Others can only access changes after they were pushed.
  • Check outs and commits can be done without a permanent connection to the server.
  • It is possible to edit commits and tidy up the local history of changes before they are published.
  • Every user can hold a copy of the whole project as backup.
  • The first pull of a project can contain many large binary files and can therefore take a while.
  • Large projects need a large amount of disk space or special treatment to pull only required elements of the whole project.


SCM-Manager is not a version control system, it is a system that is managing various version control systems from one intuitive interface. Instead of individually maintaining different CVCS’s or DVCS’s and their users and permissions. SCM-Manager allows to choose the best matching system for every project, while managing all users in one place. Besides it is easy to learn and nearly every aspect is extendable through plugins. This extendability enables users of SCM-Manager a connection between different tools. If you are using JIRA as bugtracking system, it is for example possible to close a JIRA bug out of your IDE by using a predefined syntax in the commit message. Thus effort is reduced and more time can be spent programming instead of managing tasks.

A list of existing plugins can be found here: http://plugins.scm-manager.org/scm-plugin-backend/page/index.html


There are a lot of different VCS´s and today the most common ones are Git, Mercurial and SVN. They can be divided into centralized and distributed systems. As shown above distributed systems have many advantages over centralized ones. All version control systems themselves have strenghts and weaknesses and one has to decide which one to use individually.

By using SCM-Manager it is possible to use the best matching VCS for each project and to manage all of them in one interface. This enables the user to benefit from all advantages and minimize the disadvantages. Furthermore it is possible to streamline your workflow through creating a connection between different tools by using SCM-Manager-plugins.

Best regards,
your SCM-Manager Support Team

Daniel Huchthausen

- Consultant -

When he is not exploring the wilderness, Daniel keeps himself busy with topics such as quality assurance, testing and PM methods.

©2018 Cloudogu GmbH. All rights reserved. Legal Notice | Privacy Policy

Cloudogu™, Cloudogu EcoSystem™ and the Cloudogu™ logo are registered trademarks of Cloudogu GmbH, Germany.