Version Control System (VCS): Chapter 2

Introduction

A version control system is a piece of software that helps the developers on a software team work
together and also archives a complete history of their work.

There are three basic goals of a version control system (VCS):

1. We want people to be able to work simultaneously, not serially. Think of your team as a
multi-threaded piece of software with each developer running in his own thread. The key
to high performance in a multi-threaded system is to maximize concurrency. Our goal is
to never have a thread which is blocked on some other thread.
2. When people are working at the same time, we want their changes to not conflict with
each other. Multi-threaded programming requires great care on the part of the developer
and special features such as critical sections, locks, and a test-and-set instruction on the
CPU.
Without these kinds of things, the threads would overwrite each other’s data. A
multithreaded software team needs things too, so that developers can work without
messing each other up. That is what the version control system provides.
3. We want to archive every version of everything that has ever existed — ever. And who
did it.
And when. And why.

A History of Version Control

Three Generations of Version Control

Generation Networking Operations Concurrency

First None One file at a time Locks

Centralized Merge Before commit

Second Multi-file

Prepared by: Feyisa K. Page 1

 Version Control System (VCS): Chapter 2

Distributed Commit before merge

Third Changesets

 In first generation tools, concurrent development was handled solely with locks. Only one
person could be working on a file at a time.
 The second generation tools are a fair bit more permissive about simultaneous
modifications, with one notable restriction. Users must merge the current revisions into
their work before they are allowed to commit.
 The third generation tools allow merge and commit to be separated.

File Sharing
 On a single project, a team of software engineers work together toward a release.
 All team members work on the same code and develop their respective parts.
 An engineer may be responsible for an entire class or just a few methods within a particular
class.
 So files have to be shared among developers on a team project.
 Shared files can be kept in some type of Repository(USB/SD drive, Private network drive
Or Cloud drive ) where they can be accessed and worked on by multiple individuals.

 Sharing files can lead to big problems…

Prepared by: Feyisa K. Page 2

 Version Control System (VCS): Chapter 2

Prepared by: Feyisa K. Page 3

 Version Control System (VCS): Chapter 2

 For effective management of software artifacts, especially code the version control system is
introduced.
 If you have a version control system, when you start work on a file, it can be locked so your
colleague cannot make changes at the same time.
 Or if your colleague saves a version, you'll know about it. And you'll still be able to get the
previous version back.

The Lock-Modify-Unlock Solution

 Many version control systems use a lock-modify-unlock model to address this problem.
 In such a system, the repository allows only one person to change a file at a time.
 A user must "lock" the file before he can begin making changes to it – This is often named
check-out a file.
 All other users are prohibited from making changes to the file until it is checked-in again.
 Locking a file is a lot like borrowing a book from the library; if Harry has locked a file, then
Sally cannot make any changes to it.
 The problem with the lock-modify-unlock model is that it's a bit restrictive, and often
becomes a roadblock for users!

Prepared by: Feyisa K. Page 4

 Version Control System (VCS): Chapter 2

Drawbacks :

Prepared by: Feyisa K. Page 5

 Version Control System (VCS): Chapter 2

 Harry has to remember to release his lock before Sally (or anyone else) can acquire the lock
in order to edit
 Sally has to wait for Harry to finish before editing (editing must be done sequentially)

– Harry might be adding some new methods (takes a long time)

– Harry might forget to release the lock before going home (or on vacation!)

The Copy-Modify-Merge Solution

 In this model, each user's client reads the repository and creates a personal working copy of
the file or project.
 Users then work in parallel, modifying their private copies.
 Finally, the private copies are merged together into a new, final version.
 The version control system often assists with the merging, but ultimately a human being is
responsible for making it happen correctly.

Merge conflicts

 But what if Sally's changes do overlap with Harry's changes? What then?
 This situation is called a conflict, and it's usually not much of a problem.
 When Harry asks his client to merge the latest repository changes into his working copy, his
copy of file A is somehow flagged as being in a state of conflict:
– He’ll be able to see both sets of conflicting changes, and manually choose between them.
 Note that software can't automatically resolve conflicts; only humans are capable of
understanding and making the necessary intelligent choices.
 Once Harry has manually resolved the overlapping changes (perhaps by discussing the
conflict with Sally!), he can safely save the merged file back to the repository.

Chaos?

 The copy-modify-merge model may sound a bit chaotic, but in practice, it runs extremely
smoothly.
 Users can work in parallel, never waiting for one another.
 When they work on the same files, it turns out that most of their concurrent changes don't
overlap at all; conflicts are infrequent.

Prepared by: Feyisa K. Page 6

 Version Control System (VCS): Chapter 2

 And the amount of time it takes to resolve conflicts is far less than the time lost by a locking
system.
 There is one common situation where the lock-modify-unlock model comes out better, and
that is where you have un-mergeable files.
– For example if your repository contains some graphic images, and two people change

the image at the same time, there is no way for those changes to be merged together.

Allows concurrent editing

The Repository recognizes conflicts

Prepared by: Feyisa K. Page 7

 Version Control System (VCS): Chapter 2

Conflicting versions of the files are merged

The Repository keeps both users synchronized

 Copy-Modify-Merge is generally easy to use and manage.

 Users can work in parallel
 Most of the time, concurrent changes don’t overlap

Prepared by: Feyisa K. Page 8

 Version Control System (VCS): Chapter 2

– People generally don’t edit exactly the same code simultaneously, so merging is done
automatically in many cases.

– Amount of time spent resolving conflicts are nearly always less than the time that would
be spent waiting for a lock to be released.

Features of version control systems

 All changes to a file are tracked.

– Version histories show who, what, when

 Changes can be reverted (rewound to any earlier version).

 Changes between revisions are easy to identify.

 There are many version control systems out there. Often they are divided into two groups:
―centralized‖ and ―distributed‖.

Centralized Version Control

 Centralized version control systems are based on the idea that there is a single ―central‖
copy of your project somewhere (probably on a server), and programmers will ―commit‖
their changes to this central copy.
 ―Committing‖ a change simply means recording the change in the central system. Other
programmers can then see this change. They can also pull down the change, and the
version control tool will automatically update the contents of any files that were changed.
 Most modern version control systems deal with “change sets” which simply are a groups
of changes (possibly to many files) that should be treated as a cohesive whole.
 For example: a change to a C header file and the corresponding .c file should always be
kept together.
 Programmers no longer have to keep many copies of files on their hard drives manually,
because the version control tool can talk to the central copy and retrieve any version they
need on the fly.
 Some of the most common centralized version control is Subversion (or SVN).

Prepared by: Feyisa K. Page 9

 Version Control System (VCS): Chapter 2

A Typical Centralized Version Control Workflow

When you’re working with a centralized version control system, your workflow for adding a
new feature or fixing a bug in your project will usually look something like this:
– Pull down any changes other people have made from the central server.
– Make your changes, and make sure they work properly.
– Commit your changes to the central server, so other programmers can see
them.

Subversion

 Subversion is an open-source version control system that is available and still supported
for many platforms.
 Many current open-source projects use Subversion to maintain source code control.
 Subversion’s main drawback is the centralized nature of the Repository.
 A repository is typically hosted on a server.
 Version history is on the server, not on your local PC.
 If the server or network becomes unavailable, everyone gets stuck with the working
copy they have.

Prepared by: Feyisa K. Page 10

 Version Control System (VCS): Chapter 2

Distributed Version Control (DVCS for short)

 These systems do not necessarily rely on a central server to store all the versions of a
project’s files. Instead, every developer “clones” a copy of a repository and has the full
history of the project on their own hard drive. This copy (or “clone”) has all of the
metadata of the original.
 This method may sound wasteful, but in practice, it’s not a problem. Most programming
projects consist mostly of plain text files (and maybe a few images), and disk space is so
cheap that storing many copies of a file doesn’t create a noticable dent in a hard drive’s
free space.
Modern systems also compress the files to use even less space.
 The act of getting new changes from a repository is usually called “pulling” and the act of
moving your own changes to a repository is called “pushing” In both cases, you move
change sets (changes to files groups as coherent wholes), not single-file diffs.
 One common misconception about distributed version control systems is that there
cannot be a central project repository. This is simply not true – there is nothing stopping
you from saying “this copy of the project is the authoritative one.” This means that
instead of a central repository being required by the tools you use, it is now optional and
purely a social issue.

Advantages over Centralized Version Control

 The act of cloning an entire repository gives distributed version control tools several
advantages over centralized systems:
 Performing actions other than pushing and pulling change sets is extremely fast because
the tool only needs to access the hard drive, not a remote server.
 Committing new change sets can be done locally without anyone else seeing them. Once
you have a group of change sets ready, you can push all of them at once.
 Everything but pushing and pulling can be done without an internet connection. So you
can work on a plane, and you won’t be forced to commit several bug fixes as one big
change set.
 Since each programmer has a full copy of the project repository, they can share changes
with one or two other people at a time if they want to get some feedback before showing
the changes to everyone.

Prepared by: Feyisa K. Page 11

 Version Control System (VCS): Chapter 2

Disadvantages Compared to Centralized Version Control

There are only two major inherent disadvantages to using a distributed system:

 If your project contains many large, binary files that cannot be easily compressed the
space needed to store all versions of these files can accumulate quickly.
 If your project has a very long history (50,000 change sets or more), downloading the
entire history can take an impractical amount of time and disk space.

DVCS Workflow

Prepared by: Feyisa K. Page 12

 Version Control System (VCS): Chapter 2

Prepared by: Feyisa K. Page 13

 Version Control System (VCS): Chapter 2

Prepared by: Feyisa K. Page 14