Version control - Architecture and Models

Version Control Systems: Structure and Implementation Introduction Version control systems are software tools that track changes to files and data over time, enabling multiple developers to work on the same project without overwriting each other's work. Whether you're collaborating on code, documentation, or large datasets, version control systems provide a structured way to manage revisions, handle concurrent edits, and maintain a complete history of changes. Understanding the Fundamentals How Version Control Organizes Data Version control manages changes in different ways depending on the system design. Most systems track individual files as separate items, recording changes to each one. However, more sophisticated systems like Git take a different approach: they treat the entire project as a unified whole and record changes to all modified files together in a single operation called a commit. This approach simplifies complex modifications because all related changes are grouped together logically. Working Copy vs. Repository Two key concepts form the foundation of version control: A working copy is your local, personal copy of the project files that you edit and modify. This is where you write code, update documentation, or make other changes. The repository is the authoritative storage system that permanently records all committed versions and their metadata—essentially the "official history" of your project. The basic workflow is simple: you modify files in your working copy, then commit those changes to the repository. Once committed, your changes are preserved in the official history and become available to other developers. Visualizing Revisions: The Graph Structure Revisions in version control are often illustrated as a tree-like structure with a main line (called the trunk or main branch) and side branches extending from it. However, the actual underlying structure is more complex than a simple tree. When you merge two branches—combining changes from different development lines—you create a single commit with multiple parent commits. This structure is called a directed acyclic graph (DAG). "Directed" means the connections have direction (pointing from older commits to newer ones), and "acyclic" means there are no circular loops, ensuring a consistent history. The most recent commit on any line is called the HEAD revision or the tip of that branch. Source Management Models Different version control systems manage concurrent edits using different strategies. The choice between these approaches affects how developers collaborate. File Locking: Preventing Conflicts Some version control systems prevent conflicts entirely by using file locking. With this approach, only one developer can have write access to a particular file at any given time. When you want to edit a file, you acquire a lock, preventing anyone else from modifying it until you release the lock by committing your changes. Advantage: No merge conflicts ever occur. Disadvantage: Developers must wait for others to finish editing files, reducing parallelism. Version Merging: Allowing Parallel Work More modern systems use version merging, which allows multiple developers to edit the same file simultaneously. When committing, the system attempts to automatically combine (merge) overlapping changes intelligently. How it works: The system detects which lines of the file each developer changed. If changes are in different locations, it merges them automatically. If developers modified the same lines, a merge conflict occurs that requires manual resolution—a developer must decide which changes to keep. Important distinction: Automatic merging works well for text files because the system can identify changes line-by-line. Binary files (like images or compiled code) cannot be merged automatically; they require manual intervention or specialized tools. Atomic Operations: Consistency Guarantees An atomic operation is one that either completes fully or doesn't execute at all, leaving the system in a consistent state. If an atomic operation is interrupted (by power loss, network failure, etc.), it automatically rolls back rather than leaving partial changes. Commits are typically atomic: either all changes in the commit are recorded together, or none of them are. This guarantees that users never see a partially committed state. This is particularly important in centralized systems where multiple developers pull from the same server. Two Fundamental Architectures Centralized Version Control In centralized version control, there is a single authoritative server holding the complete repository. All developers check out files from this server, work on them locally, and then check them back in. How it works: You download files from the central repository to your working copy You edit the files locally You commit changes back to the central server Other developers pull the latest changes to sync with your work Key limitation: Most operations require network access to the central server. You cannot commit, view history, or perform most version control operations while offline. Advantage: There is a single, clear source of truth—the central server always has the canonical version. Distributed Version Control Distributed version control fundamentally changes the architecture: instead of a central server, each developer's machine holds a complete copy of the entire repository, including the full history. Key differences: Your working copy IS a repository. Every clone (copy) is a complete, standalone repository No single canonical copy exists; any repository can serve as the source of truth You can commit, view history, and perform most operations entirely offline Synchronization happens by exchanging patches (change-sets) between repositories Pushing and pulling: When you want to share changes, you push your local commits to another repository (or a shared server). When you want to receive others' changes, you pull their patches and merge them into your repository. Major advantages of distributed systems: Speed: Common operations like committing and viewing history don't require network communication Resilience: Every clone is a complete backup. If the central server is lost, any developer's machine contains the full project history Offline work: You continue working normally without network access and synchronize later Data Version Control While traditional version control excels at managing code and text, data version control extends these concepts to large datasets and machine learning models. These systems track changes to data files alongside source code, enabling reproducibility and tracking the evolution of datasets used in analysis and training. The Complete Picture Understanding version control requires seeing how these concepts interact. A developer starts with a working copy of the repository, makes changes, and commits them back. In centralized systems, the central server immediately records these changes; in distributed systems, the developer's local repository records the changes first, and then they can be shared through push operations. Branches allow multiple parallel development efforts. Merges combine these efforts. Atomic commits ensure consistency. Whether the system is centralized or distributed determines whether most operations require network access and how resilient the system is to data loss.