Revision control, also known as version control and source control (and an aspect of software configuration management), is the management of changes to documents, computer programs, large web sites, and other collections of information. Changes are usually identified by a number or letter code, termed the "revision number", "revision level", or simply "revision". For example, an initial set of files is "revision 1". When the first change is made, the resulting set is "revision 2", and so on. Each revision is associated with a timestamp and the person making the change. Revisions can be compared, restored, and with some types of files, merged.

1. Getting Started - About Version Control
Background on version control tools
Whether your software project is large or small, we generally recommend that you
use version control as early as possible in the lifecycle of your project.
1
Ramakrishna.Pathuri

2. About Version Control
What is version control, and why
should you care?
Version control is a system that records changes to a file or
set of files over time so that you can recall specific versions
later. Even though the examples in this book show software
source code as the files under version control, in reality any
type of file on a computer can be placed under version
control.
2
Ramakrishna.Pathuri

3. Which Version Control I should I Use
?
Team Foundation Version Control (TFVC) is a centralized version
control system. Typically, Team members have only one version of
each file on their dev machines. Historical data is maintained only on
the server. Branches are path-based and created on the server..
Git is a decentralized version control system. Each developer has a
copy of the entire source repository on their dev machine. Developers
can commit each set of changes on their dv machine and perform
version control operations such as history and compare without a
network connection..
3
Ramakrishna .Pathuri

4. Centralized Version Control Systems
The next major issue that people encounter is that they need to
collaborate with developers on other systems.
To deal with this problem, Centralized Version Control Systems (CVCSs)
were developed. These systems, such as CVS, Subversion, and
Perforce,
have a single server that contains all the versioned files,
and a number of clients that check out files from that central place.
For many years, this has been the standard for version control
4
Ramakrishna.Pathuri

5. Centralized Version Control Systems
5
Ramakrishna.Pathuri

6. Distributed Version Control Systems
This is where Distributed Version Control Systems (DVCSs) step in.
In a DVCS (such as Git, Mercurial, Bazaar or Darcs), clients don’t just
check out the latest snapshot of the files: they fully mirror the repository.
Thus if any server dies, and these systems were collaborating via it, any
of the client repositories can be copied back up to the server to restore it.
Every checkout is really a full backup of all the data
This allows you to set up several types of workflows that aren’t possible
in centralized systems, such as hierarchical models.
6
Ramakrishna.Pathuri

7. Distributed Version Control Systems
7
Ramakrishna.Pathuri

8. Getting Started - A Short History of Git
The major difference between Git and any other VCS
(Subversion and friends included) is the way Git thinks
about its data..
Conceptually, most other systems store information as a list
of file-based changes. These systems (CVS, Subversion,
Perforce, Bazaar, and so on) think of the information they
keep as a set of files and the changes made to each file
over time
8
Ramakrishna.Pathuri

9. Checkins Over Time
9
Ramakrishna.Pathuri

10. Git thinks of its data more like a set of snapshots of a mini
filesystem.
Every time you commit, or save the state of your project in Git, it
basically takes a picture of what all your files look like at that
moment and stores a reference to that snapshot.
To be efficient, if files have not changed, Git doesn’t store the
file again—just a link to the previous identical file it has already
stored
10
Ramakrishna.Pathuri

11. Git stores data as snapshots of the
project over time.
11
Ramakrishna.Pathuri

12. Getting Started - A Short History Team
Foundation Version Control
use Team Foundation Version Control (TFVC) to scale from
small to large projects, and by using server
workspaces, you can scale up to very large codebases with
millions of files per branch and large binary files..
12
Ramakrishna.Pathuri

13. Team Foundation Version Control
(centralized)
Team Foundation Version Control (TFVC) is a centralized version control system.
Typically, Team members have only one version of each file on their dev
machines. Historical data is maintained only on the server. Branches are pathbased and created on the server.
TFVC enables two models for your team to make changes:
Check out/check in in server workspaces: Before making changes, team
members publicly check out a files. Most operations require developers to be
connected to the server. (In the past teams blocked more than one person from
checking out, but this is now less common.) This system facilitates locking work
flows. Other systems that work this way include Visual Source Safe, Perforce,
and CVS.
Edit and commit from local workspaces: Each team member takes a copy of the
latest version of the codebase with them and works offline as needed. Developers
check in their changes and resolve conflicts as necessary. Another system that
works this way is Subversion.
13
Ramakrishna.Pathuri

14. Thank You …
Ramakrishna.Pathuri
SyncApps Online Ventures Pvt.ltd
Ramakrishna.p@easybus.in
14
Ramakrishna.Pathuri