SVN Basic Concepts


What is Version Control System (VCS) ?

Version Control System is a software that helps software developers to work together and also maintains complete history of their work.

Following are goals of Version Control System.

  • Allow developers to work simultaneously.

  • Do not overwrite each other’s changes.

  • Maintain history of every version of everything.

Version control system is divided into two categories.

  • Centralized version control system (CVCS) and

  • Distributed/Decentralized version control system (DVCS)

In this tutorial session we will concentrate only on Centralized Version Control System and especially Subversion. Subversion falls under centralized version control system, meaning that it uses central server to store all files and enables team collaboration.

Version Control Terminologies

Let us start by discussing some of the terms that we will be using in our tutorial.

  • The Repository: A repository is the heart of any version control system. It is central place where developers store all their work. Repository not only stores files but also history. Repository is accessed over a network, with repository acting as a sever and version control tool acting as a client. Client can connect to repository, and then they can store/retrieve their changes to/from repository. By storing changes, a client makes available these changes to other people and by retrieving changes; a client takes other people changes as a working copy.

  • Trunk: The trunk is a directory where all the main development happens and is usually checked out by developers to work on the project.

  • Tags: The tags directory is used to store named snapshots of the project. Tag operation allows to give descriptive and memorable names to specific version in the repository.

    For example LAST_STABLE_CODE_BEFORE_EMAIL_SUPPORT is more memorable than

    Repository UUID: 7ceef8cb-3799-40dd-a067-c216ec2e5247 and

    Revision: 13

  • Branches: Brach operation is used to create another line of development. It is useful when you want your development process to fork off into two different directions. For example, when you release version 5.0, you might want to create a branch so that development of 6.0 features can be kept separate from 5.0 bug-fixes.

  • Working copy: Working copy is a snapshot of the repository. The repository is shared by all the team, but people do not modify it directly. Instead each developer checkout working copy. The working copy is private workplace where developer can do their work within isolated from the rest of the team.

  • Commit changes: Commit is a process of storing changes from private workplace to central server. After commit, changes are made available to all the team. Other developer can retrieve these changes by updating their working copy. Commit is atomic operation. Either whole commit succeeds or is rolled back. Users never see half finished commit.