Version Control System

Presented By

E.SAIKUMAR

Development Scenario #1You’re working on the 2.0 version of “your great app.” But 2.0 doesn’t quite compile yet… and customer finds a critical bug in 1.0, which must be fixed ASAP.

If you're smart, you have a copy of your 1.0 source.You make the change and release, but how to you merge your changes into your 2.0 code?

If you're not so smart, you have NO source code saved. You have no way to track down the bug, and you loose face until 2.0 is ready.

Development Scenario #2Your working on a large scale development project. But you believe one of your team members has added malicious code to the project. How do you monitor what they’ve changed in your 10,000 line, or 100,000 line project?

i.e. How do you add accountability to a text file?

Version control

Version control manages change

The only constant is change (Heraclitus)

Why version control:

• They allow teams to collaborate• They manage change and allow for

inspection • They track ownership• They track evolution of changes• They allow for branching• They allow for continuous integration

Version Control: The Ancients

1972 – Source Code Control System (SCCS) Born out of Bell Labs, based on interleaved deltas No open source implementations as far as I know

1982 – Revision Control System (RCS) Released as an alternative to SCCS Operates on single files Open source implementation hosted at GNU

Version control : The centralized

• One centralized server with the revision information

• Clients checkout a working copy locally• Most operations happen on the server• Linear revision history

Version Control: The Centralized• 1990 – Concurrent Versions System (CVS)

Initially released as some scripts on top of RCS Made branching possible for most people Revisions by commits are per file , No atomic commit,Not really maintained anymore...

• 2000 – Subversion (SVN)

Released as an improvement to CVS

Atomic commits via transactions Open

source implementation hosted at Apache

Workspaces & Repository

Your WorkspaceCover.rtf (ver 1.2)Chapter 1.txt (ver 1.32)Chapter 2.txt (ver 1.20)Chapter 3.txt (ver 1.14)

RepositoryCover.rtf (ver 1.2)Chapter 1.txt (ver 1.32)Chapter 2.txt (ver 1.20)Chapter 3.txt (ver 1.15)

Workspace Workspace Workspace

The Repository

• The repository holds information including dates, labels, branches, versions, etc.

• The repository holds just the changes between versions, saving space.

• Also referred to as the a “depot” or “root”• Often held on a central server

Checkout & Commit

WorkspaceCover.rtf (ver 1.2 - Modified)Chapter 1.txt (ver 1.32)Chapter 2.txt (ver 1.20 - Modified)Chapter 3.txt (ver 1.14)Chapter 4.txt (ver 1.1 - New)

RepositoryCover.rtf (ver 1.2)Chapter 1.txt (ver 1.32)Chapter 2.txt (ver 1.20)Chapter 3.txt (ver 1.14)

Commit

RepositoryCover.rtf (ver 1.3)Chapter 1.txt (ver 1.32)Chapter 2.txt (ver 1.21)Chapter 3.txt (ver 1.14)Chapter 4.txt (ver 1.1)

Checkout & Modify

Checkout

• With checkout commands, one can summon files or sets of files from the repository based on date, tag, branch, or any of a number of other criteria.

Update

WorkspaceCover.rtf (ver 1.4 - Updated)Chapter 1.txt (ver 1.35)Chapter 2.txt (ver 1.21 - Conflict)Chapter 3.txt (ver 1.18)Chapter 4.txt (ver 1.3 - New)

RepositoryCover.rtf (ver 1.4)Chapter 1.txt (ver 1.35)Chapter 2.txt (ver 1.22)Chapter 3.txt (ver 1.18)Chapter 4.txt (ver 1.3)

Update

WorkspaceCover.rtf (ver 1.2)Chapter 1.txt (ver 1.35)Chapter 2.txt (ver 1.21)Chapter 3.txt (ver 1.14)

Update

• Update commands will automatically bring your workspace up-to-date with the latest (or however you specify) files from the repository.

• Update automatically merges non-exclusive changes between files and initiates conflict resolution if necessary.

• Updates involving conflicts solicit information from the user how they wish to have a conflict resolve.

Version Control: The Distributed

• Every client has a copy of the full repository locally

• All repository operations are local (except sharing)

• Intelligent network operations when sharing content

• A very non linear revision history• Large online communities to share changes

Version Control: The Distributed

• 2001 – GNU arch First open source DVCS Deprecated; not maintained anymore

• 2005 – Git Created as the SCM for the Linux kernel by Linus

• 2005 – Mercurial (Hg) Cross-platform DVCS

• 2007 – Bazaar (BZR) Sponsored by Canonical

Branches everywhere• Creating and destroying branches are simple

operations so it's easy to experimen with new ideas

• Very easy to isolate changes

Merging

• DVCS are all about merging• Merges are just the weaving together of two (or

more) local branches into one • However, unlike CVCS, you don't have to

specify anything about where you're merging from and to; the trees automatically know what their split point was in the past, and can work it out from there.

Collaboration:• Developers can easily collaborate directly

without needing a central authority or dealing with server administration costs

Disconnected operations rule!• Developers can still be productive and not

worry about a central server going down... remember the days of complaining that CVS was down and you couldn't work?

File Annotation

• Allows you to see who changed what when, line by line.

• Useful for tracking bugs.

• Can be used in combination with diff and history for even more information.

Conclusion

• The future of version control is distributed!• Lessons Learned at Eclipse moving to a DVCS• Version controller enables a nice code review

workflow

??..

Want to Know more..!