Your SlideShare is downloading. ×
Introduction to Version Control and Configuration Management
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Introduction to Version Control and Configuration Management

4,431
views

Published on

Published in: Technology

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
4,431
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
84
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Introduction to Version Control and Configuration Management Philip Johnson Collaborative Software Development Laboratory Information and Computer Sciences University of Hawaii Honolulu HI 96822
  • 2. Objectives
    • Understand motivation for configuration management technologies.
    • Be able to download/install/use a SVN client.
    • Be able to use SVN for configuration management of your course project.
  • 3. Why do we care
    • Software is written:
      • As a combination of modules
      • In one or more languages
      • For one or more applications
      • Using one or more libraries
    • Things that may (will) change over time:
      • The modules required and used
      • The languages employed
      • The application requirements
      • The libraries
    • Each change could cause the system to break.
  • 4. You know you have a CM problem when…
    • “ But the system was working fine yesterday! What happened?”
    • “ But I can’t reproduce your bug in my copy of the system!”
    • “ But I already corrected that code last week! What happened to my fix?”
    • “ I wonder if that bug was fixed in this copy too?”
  • 5. CM Defined
    • Configuration management attempts to identify and track all relevant elements of the configuration of a system, so that all possible errors can be identified, and possible solutions to the problems found.
    • Version control is a special case of configuration management, where we are concerned with maintaining multiple versions of a software system.
    • Defect tracking systems monitor the status of error reports from first identification to resolution. Defect tracking relates to CM because defects occur as a result of changes, and defect removal typically requires a change in configuration.
  • 6. The Three Classic CM Problems
    • Any configuration management approach must address at least the following “classic” problems:
    • The double maintenance problem
      • Must prevent occurrence of multiple copies of the same file that must be independently updated.
    • The shared data problem
      • Must allow two or more developers to access the same file/data.
    • The simultaneous update problem
      • Must prevent “clobbering” when two developers update the same file at the same time.
      • “ clobbering”: only the second developer’s changes survive.
  • 7. Versions vs. Configurations (Traditional)
    • Files exist in multiple versions
      • Sequences of updates over time
      • Parallel variants
    • Systems exist in multiple configurations
      • For different platforms
      • For different customers
      • For different functionality/pricing levels
    Foo.java (1.1) Foo.java (1.2) Foo.java (1.3) Foo.java (1.4) Foo.java (1.5) Foo.java (1.2.1) Foo.java (1.2.2) Bar.java (1.1) Bar.java (1.2) Bar.java (1.3) 1.0.0 1.0.1 1.1.0
  • 8. Version Control
    • Version control systems support:
      • Multiple versions of a file
      • Multiple paths of file revision
      • Locking to prevent two people from modifying the same file at the same time
      • Recovery of any prior version of a file
      • Efficient storage via “deltas” (forward or backward)
    Foo.java (1.1) Foo.java (1.2) Foo.java (1.3) Foo.java (1.4) Foo.java (1.5) Foo.java (1.2.1) Foo.java (1.2.2) Branch Merge
  • 9. RCS: Revision Control System
    • When foo.java is put under RCS control, a new file called RCS/foo.java,v is created that represents:
      • The most recent version of foo.java
      • Backward deltas allowing reconstruction of any older version of the file in space-efficient manner.
      • Information on who has a lock on the file (if anyone)
    • For details, download, etc:
      • http://www.gnu.org/software/rcs/
  • 10.  
  • 11. Example RCS Commands
    • % ci foo.java
      • Submit foo.java for version control, or submit updated version.
      • Creates RCS/foo.java,v
      • Deletes foo.java
      • Prompts you to supply a string documenting updates.
    • % co foo.java
      • Obtain read only copy of latest version of foo.java.
    • % co –l foo.java
      • Request a lock so file is read/write
    • % rcsmerge –r1.4 –r1.2.2 foo.java
      • Merge multiple versions into one file
    • % rcsdiff –r1.4 –r1.2.2 foo.java
      • See differences between versions 1.4 and 1.2.2
  • 12. RCS and the 3 CM Problems
    • The double maintenance problem
      • RCS provides a repository with a single “master copy” of each file.
    • The shared data problem
      • Multiple developers can access the directory containing the checked out version of the file.
    • The simultaneous update problem
      • To edit a file, a developer must obtain a lock.
      • RCS changes file permissions/ownership to implement the lock.
  • 13. RCS Summary
    • Free, open source, former “industry standard”
    • Easy to install and setup.
    • Non-GUI, unix-based, command line interface.
    • Provides version control, not configuration management.
    • All developers must access the same (Unix) file system to solve double maintenance and shared data problems.
    • Locking is “pessimistic”
      • Leads to many emails with “Please release lock on file foo.java.”
  • 14. CVS: Concurrent Versions System
    • Uses RCS as backend for version control, adds configuration management support.
    • Client-server architecture enables:
      • checkin and checkout over Internet
      • Developers do not need to access single (Unix) file system
    • “ Optimistic” locking
      • Multiple developers can modify same file simultaneously.
      • At checkin, any “merge conflicts” are detected and given to developers to resolve.
    • Versions and configurations still on a “per-file” basis
      • SVN will take a different approach.
  • 15.  
  • 16. Basic steps for CVS
    • Administrator sets up CVS server and provides developers with CVS accounts and passwords.
    • Developers configure their workstations with CVS repository location, account, and password information.
    • Basic development cycle:
      • Check out a copy of system to your computer.
      • Edit files locally.
      • Commit your changes to repository when ready.
      • Update your local code tree to synchronize it with repository when desired.
      • Address merge conflicts as they occur.
      • Tag a set of file versions to create a configuration when ready to release.
  • 17. CVS and the 3 CM problems
    • The double maintenance problem
      • CVS uses RCS to provide a repository with a single “master copy” of each file.
    • The shared data problem
      • Multiple developers can create local copies of the master copy to work on.
    • The simultaneous update problem
      • Multiple developers can edit a file simultaneously!
      • File clobbering is prevented by CVS notifying a developer when an attempt to commit creates “merge conflicts”.
      • CVS creates a “merged” file with all changes.
  • 18. CVS Summary
    • Free, open source, recent “industry standard”
    • Centralized server architecture
    • Non-trivial to install server; security issues.
    • GUI and CLI clients available for many platforms.
    • Provides version control and configuration management but not:
      • Build system
      • Defect tracking
      • Change management
      • Automated testing
    • Optimistic locking creates work during merge.
  • 19. Subversion
    • Designed as a "compelling replacement" for CVS.
      • CVS code base old and crufty.
      • File-based versions create problems.
      • The current “industry standard”
    • Similar to CVS in many respects (checkout, commit, optimistic locking)
    • Some major differences:
      • Back-end repository not files, but a DB.
      • Versions are not file-based, but repository-wide.
      • "Directory" based tags and branches.
      • Arbitrary metadata.
    • Downloads, etc: http://subversion.tigris.org
  • 20.  
  • 21. SVN vs. CVS in a nutshell
    • Repository:
      • CVS uses flat files; SVN uses BerkeleyDB
    • Speed:
      • SVN is faster.
    • Tags and Branches:
      • CVS uses metadata; SVN uses folder conventions
    • File Types:
      • CVS designed for ASCII, supports binary via 'hacks'; SVN handles all types uniformly.
    • Transactional commit:
      • SVN supports; CVS does not.
    • Deletion and renaming:
      • CVS support is bogus; SVN support is good.
    • Popularity:
      • Most popular for new projects, but Git is gaining!
  • 22. Git
    • A distributed version control system.
      • multiple redundant repositories
      • branching is a “first class concept”
    • Every user has a complete copy of the repository (including history) stored locally.
    • No “commit access”. Instead, you decide which users repositories to merge with your own.
    • See Linus Torvalds talk on Git on YouTube.
    • Mercurial is similar to Git.
  • 23.  
  • 24. Git vs. SVN
    • Advantages of Git:
      • Most operations much faster.
      • Git requires much less storage than SVN.
      • Git supports decentralized development.
        • No need for a “czar”
        • More workflows possible than with SVN
    • Advantages of SVN:
      • Centralized repository means you know where the code is.
      • Access control possible.
      • Sometimes a “czar” is helpful for project coordination.
  • 25. Yet More CM Alternatives
    • Bazaar (bzr):
      • Decentralized configuration management
        • P2P, not centralized server
      • Individuals publish branches to a web server.
    • BitKeeper:
      • Decentralized
      • Not open source!
    • ClearCase, Visual Source Safe, etc.
      • Commercial, costly solutions.
      • Include additional services (workflow, issue tracking, etc.)
  • 26.  

×