Coding With Fun
Home Docker Django Node.js Articles Python pip guide FAQ Policy

SVN basic concepts


May 25, 2021 SVN


Table of contents


What is a version control system (VCS)

Version Control System (VCS) is software that helps software developer teams work and maintain their complete work history. Here are the goals of the version control system (VCS).

  • Allow developers to work at the same time
  • Everyone's changes are not rewritten
  • Maintain the entire history of each version

VCS is divided into two categories

  • Centralized Version Control System (CVCS) and
  • Dispersed or unsyscionable version control system (DVCS)

In this tutorial, we focus only on centralized version control systems, especially Subversion, which is based on centralized version control systems, which means using a unified server to enable teams to collaborate.

Version-controlled terminology

Let's start with some of the terms we'll use in this tutorial

  • Warehouse: A repository is the core of any version of the system, it is the repository where developers keep their work, the repository not only processes files but also has history, it needs access to the network, plays the role of server, version control tools act as clients, clients can connect to the warehouse, then they can store or extract from the warehouse. B y saving these changes, one client's changes can be retrieved by others, and one client can make other people's changes as a working copy.

  • Trunk: Trunk is the directory where the primary development is located and is often viewed by project developers.

  • Tags: Tags directories are used to store snapshots of named items, and label operations allow you to give a description of a specific version of the repository and an unforgettable name. F or example, LAST_STABLE_CODE_BEFORE_EMAIL_SUPPORT is more memorable than repository UUID: 7ceef8cb-3799-40dd-a067-c216ec2e5247 and Vision: 13.

  • Branching: Branch operations are used to create another line of development, which is useful when you want to copy the development process in two different directions. For example, when you release version 5.0, you might want to separate the bug fixes from 5.0 to create a branch that develops the 6.0 feature.

  • Working copy: A working copy is a snapshot of the warehouse. T he repository is shared by all members, but people don't modify it directly, instead each developer checks the working copy, which is a private workspace where developers can do their own work independently of other members.

  • Commit changes: Submitting is the process of saving changes, from a private workspace to a central server. A fter you commit, the changes are available to all members and are extracted by other developers by updating the working copy. A commit is an atomic operation, either all commits succeed or roll back, and the user will never see half of the commit completed.