CHAPTER TWO

VERSION CONTROL By: Fozia Abako

SYSTEM
OUTLINE
• Version Control system •Feature Of VCS
•Basic Goals Of VCS •Centralized VCS
•History of VCS •Subversion
•File sharing •Pros and Cons Of over CVS
•The lock-Modify-solution •DVCS workflow
•The Copy-Modify-Merge
VERSION CONTROL SYSTEM
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.
 A way to keep track of changes to files (& folders) Between multiple
authors (developers)
 Over time files evolve and change. Tracking these changes can be difficult,
since the changes stem from different project teams.
 Version control allows users to maintain the integrity of files that are subject
to change.
CONT.…
Version control systems provide users the ability to serialize changes to a given file.
Most such systems also allow users to revert(change) to an earlier form of a file.
Anything can be stored under a good version control system including source code,
documents, images, and binaries.
THERE ARE THREE BASIC GOALS OF
A VERSION CONTROL SYSTEM (VCS):
1. We want people to be able to work simultaneously, not serially
2. When people are working at the same time, we want their changes to not conflict
with each other.
3. We want to archive every version of everything that has ever existed ever in
addition who did it ,when And why.
A HISTORY OF VERSION
CONTROL
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.
CONT.….
CONT.…
CONT.…
For effective management of software artifacts, especially code the version control
system is introduced.
If you have a version control system, when you start to 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!
CONT.….
CONS

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.
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-mergable 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.
CONT.…
Allows concurrent editing The Repository recognizes conflicts
CONT.…
Conflicting versions of the files are The Repository keeps both users
merged 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
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.
CONT.…
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).
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.
DISTRIBUTED VERSION
CONTROL
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.
PROS 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.
CONS 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
THANK YOU