________   ___   _________        ________   ________    ________          ________   ___   _________   ___  ___   ___  ___   ________     
            |\   ____\ |\  \ |\___   ___\     |\   __  \ |\   ___  \ |\   ___ \        |\   ____\ |\  \ |\___   ___\|\  \|\  \ |\  \|\  \ |\   __  \    
            \ \  \___| \ \  \\|___ \  \_|     \ \  \|\  \\ \  \\ \  \\ \  \_|\ \       \ \  \___| \ \  \\|___ \  \_|\ \  \\\  \\ \  \\\  \\ \  \|\ /_   
             \ \  \  ___\ \  \    \ \  \       \ \   __  \\ \  \\ \  \\ \  \ \\ \       \ \  \  ___\ \  \    \ \  \  \ \   __  \\ \  \\\  \\ \   __  \  
              \ \  \|\  \\ \  \    \ \  \       \ \  \ \  \\ \  \\ \  \\ \  \_\\ \       \ \  \|\  \\ \  \    \ \  \  \ \  \ \  \\ \  \\\  \\ \  \|\  \ 
               \ \_______\\ \__\    \ \__\       \ \__\ \__\\ \__\\ \__\\ \_______\       \ \_______\\ \__\    \ \__\  \ \__\ \__\\ \_______\\ \_______\
                \|_______| \|__|     \|__|        \|__|\|__| \|__| \|__| \|_______|        \|_______| \|__|     \|__|   \|__|\|__| \|_______| \|_______|
                                                                                                                                                        
                                                                                                                                                        
                                                                                                                                                        
            
        

• git-basics

In the initial phase, when developers had no version control systems available, they relied on manually keeping multiple copies of files in local storage to prevent data loss. However, more experienced developers adopted a slightly better approach—storing copies with timestamps to track updates.

PROBLEMS WITH NAIVE AND CLEVER APPROACHES

• Since the entire file is duplicated every time a change is made, this approach consumes a large amount of storage space.
• Manually identifying changes across multiple versions is tedious, inefficient, and error-prone.
• Keeping track of updates using timestamps does not prevent accidental overwrites or loss of important changes.

SOLUTION

To overcome these issues, **Version Control Systems (VCS)** were introduced. A VCS is a system that saves data at different checkpoints, allowing users to retrieve previous versions in case of accidental modifications or deletions. It also enables reverting to a stable state if compatibility issues arise and helps track changes over time.

LOCAL VERSION CONTROL SYSTEM (VCS)

To improve upon manual versioning, programmers created a **Local Version Control System**, where a database keeps track of all changes made to a file under revision control.

This approach addresses several issues:

• Maintains an ordered history of recent modifications.
• Each file has its own version-controlled database.
• Reduces storage consumption by tracking only changes instead of duplicating entire files.

REVISION CONTROL SYSTEM (RCS)

A **Revision Control System (RCS)** was introduced to further optimize storage by storing **only the differences** (patches) between versions instead of full copies of each file. This approach is **more efficient** since we no longer need to save entire files for every change.

To reconstruct any version of a file, RCS starts from the **base version** and applies all patch sets sequentially to rebuild the desired version.

Example:

**Base Version:** `"Hello World"`

**Patch 1:** `+!` → `"Hello World!"`

**Patch 2:** `+ Welcome` → `"Hello World! Welcome"`

If we want to retrieve **Version 1**, RCS starts from the base version and applies patches sequentially **until Patch 1** is reached:

Base Version + Patch 1: `"Hello World"` + `"!"` = `"Hello World!"`

PROBLEMS WITH LOCAL VCS

While local VCS solves some issues, it introduces new limitations:

• **No Collaboration:** Local VCS is limited to a single system, meaning multiple developers cannot work on the same project collaboratively.
• **No Remote Backup:** If the local machine crashes or data is lost, all version history is lost as well.
• **Limited Change Tracking:** Although RCS tracks changes efficiently, it does not support branching, merging, or distributed development.

CENTRALIZED VERSION CONTROL SYSTEMS (CVCS's)

In a **Local VCS**, users cannot collaborate efficiently because each developer maintains their own **individual version control database**. This makes it difficult for others to contribute, track progress, or understand ongoing changes. Additionally, managing updates requires **direct communication** between developers, making collaboration inefficient.

To solve these issues, **Centralized Version Control Systems (CVCSs)** were introduced. In a **CVCS**, all versioned files are stored in a **centralized database**, allowing multiple developers to:

Work collaboratively on the same project. Track changes made by other team members. Avoid conflicts and ensure smoother project management.

This architecture also gives administrators **greater control** over the workflow. Since all changes go through a central server, admins can **review modifications, approve or discard changes, and maintain a clear history of the project's development**. This makes **CVCSs more structured and manageable** compared to **Local VCS**.

PROBLEM WITH CVCS'S

While **Centralized Version Control Systems (CVCSs)** solve the collaboration issues of Local VCS, they come with their own challenges. The biggest drawback is the **Single Point of Failure**, meaning:

• If the **centralized server goes down**, no one can make changes or access version history until it is restored.
• If the **central database is corrupted or lost**, the entire project history and data could be permanently lost—**unless proper backups are maintained**.

These limitations led to the development of **Distributed Version Control Systems (DVCSs)**, which address the risks associated with centralization.