SVN Version control system

 What is Version Control System?

Version Control System (VCS) is a software that helps software developers to work together and maintain a complete history of their work.

Following are the goals of a Version Control System.

  • Allow developers to work simultaneously.
  • Do not overwrite each other’s changes.
  • Maintain history of every version of everything.

A VCS is divided into two categories.

  • Centralized Version Control System (CVCS), and
  • Distributed/Decentralized Version Control System (DVCS).

In this tutorial, we will concentrate only on the 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 this tutorial.

  • Repository: A repository is the heart of any version control system. It is the central place where developers store all their work. Repository not only stores files but also the history. Repository is accessed over a network, acting as a server and version control tool acting as a client. Clients can connect to the repository, and then they can store/retrieve their changes to/from repository. By storing changes, a client makes these changes available to other people and by retrieving changes, a client takes other people's 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: Branch 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 teams, but people do not modify it directly. Instead each developer checks out the working copy. The working copy is a private workplace where developers can do their work remaining 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 developers can retrieve these changes by updating their working copy. Commit is an atomic operation. Either the whole commit succeeds or is rolled back. Users never see half finished commit.

We can deep dive here on some points :

Comments

Post a Comment

Popular posts from this blog

Different Types of Reports in Scrum - Agile

Image
  Introduction to Agile Reporting I’m not going to elaborate on the Agile Framework itself here.  1. Sprint Burndown At a Sprint-level, the burndown presents the  easiest way to track and report status  (the proverbial  Red / Amber / Green ), i.e., whether your Sprint is on or off-track, and what are the chances of meeting the Sprint goals. The burndown chart – when used right – can provide  near-real time updates  on Sprint progress. “If your team do it right, then they would take in just the right amount of work into a sprint.” At the beginning of a Sprint, the Scrum team perform Sprint Planning and agree to take on development work worth a certain number of Story points. This forms the basis for the Sprint Burndown chart. The total story points agreed at the beginning of the sprint make up the y-axis, and the individual dates in the Sprint make up x-axis. If your team do it right, then they would take in just the right amount of work into ...
Read more

Agile Retrospective

Image
  Guide to agile retrospectives for continuous improvement An agile retrospectives is an opportunity for agile development teams to reflect on past work together and identify ways to improve. Agile teams hold retrospective meetings after a time-boxed period of work is complete (typically a sprint lasting two to four weeks). During the agile retrospective, the team discusses what went well, what did not go as planned, and how to make the next work period better. Even if you are not on a development team, you can probably relate to the concept of retrospection. Have you ever worked hard on something only to realize later that you should have done it differently? It is not always a good feeling, but the solutions you uncover in hindsight can be valuable input for your next try. The same goes for your successes — acknowledging what went well and is worth repeating can be just as impactful. What is an agile retrospective? In short, an agile retrospective is a meeting...
Read more

Agile product management

Image
  What is agile product management? How do we define agile product management? It is a product development philosophy that emphasizes a flexible and human — rather than a rigid process- or tool-oriented — approach to defining product strategy and carrying out work. Teammates focus heavily on customer feedback to make improvements and adjust roadmaps throughout the product management process. This creates more responsive teams, leads to quicker iterations, and creates a more lovable experience overall. Benefits of agile product management Agile redefines how product managers think about planning and building products. Traditionally, new customer experiences were planned, designed, implemented, and tested in a step-by-step way. This meant that new functionality was delivered sequentially. Once requirements were defined and handed off to the development team, it was difficult to make any changes. The failure rate of large-scale and lengthy software development proj...
Read more