In this article, we'll talk about version control classifications and their usage recommendations based on the different factors and constraints of software projects.

Software Version Control (SVC) is the term for the practices, tools, and software packages used to manage software project assets  (e.g. source code).

There are two classifications for VC packages: centralized (CVC) and de-centralized (DCVC). Choosing one over the other depends on many factors, including :

1. Project scale

2. Team geographical locations

3. Team expertise 

4. Agility.  

The current most popular available open-source options for CVC is Subversion, and the most popular for DCVC is Git.

When to Use Centralized Version Control?

In small-scale projects with relatively close geographical areas and low-level of expertise, CVC is the preferred method since it is easier to manage, and it will reduce the chance of conflicts.

However, it requires centralized seniority expertise to ensure stability through a continuous code review process. In this case, the software development policy should ensure that only low-level and short-term tasks are assigned to developers (hours up to one day) by experienced architects or software designers.

When to Use De-Centralized Version Control?

On the other hand, DCVC depends on a situation where developers have more maturity and expertise to handle more higher-level long-term tasks. Also, they should have the ability to make architectural and design decisions. Project leadership should force standardization of coding and naming conventions, design, and architecture decisions to ensure consistency across the different project components, which may increase the cost of development in case there is a failure to do so.

Update: July 6,2016

Below are some questions that may clarify my perspective about CVC and DCVC.

1. Are junior developers usually assigned long-term or short term tasks?

2. Is Git designed for short or long-term commits on server?

3. Which one is easier to learn (conceptual and practical) for junior-developers?

4. In distributed and remote geographical areas, with different working timezones, how the developers can back up and track their work in case of version control server or network failure?

5. When the developers have larger privileges to design and implement their own tasks and components (such as micro-services), what is more practical and easier for them during the development, to commit locally or to commit on server using branching? Who normally get this privileges , junior  or senior developers?

6. In projects with relatively high number of developers working on the same components (more than 3 developers), how it will easy to resolve the conflicts if Git is used and the tasks are relativly long term (2-10 days)?

7. What is the percentage of junior developers and immature developers who able to commit to architectural design, and coding convention standards with minimal supervision?

8. How to ensure architecture, design and convention consistency across projects for long-term and distributed tasks if Git is used?

Jalal Kiswani
http://www.jalalkiswani.com/