version control system
TRANSCRIPT
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..!