Subversion Power Point Slides -

Document Sample
Subversion Power Point Slides - Powered By Docstoc
 David Turner
 Dec 24, 2007
        What is Subversion?
• Subversion is a version control system.
• A version control system allows users to
  manage files, directories, and the changes made
  to them.
• Subversion can manage any sort of file
  collection (not only source code).
Working copy

Working copy              Repository

Working copy
   Reasons to Use Subversion
• You can work more easily with other developers
  on software development projects.
• You can undo changes to obtain earlier versions
  of files.
• Subversion is well known and free.
• Subversion has been under development since
     CVS versus Subversion
• Subversion fixes problems with CVS.
  (See subversion book for details.)
• Subversion is being adopted as a
  replacement for CVS.
     Subversion Architecture
  Repository versus Working Copy
• Project code is stored in a server in a data store
  referred to as a “repository.”
• Developers “check out” copies of the project
  code into their local environments. These
  copies are referred to as “working copies.”
• After making changes to a working copy, the
  developer “commits” changes to the repository.
• Other developers get these changes by
  “updating” their working copies.

∆                ∆              ∆

    previous         previous       current
    to the           version        version
            Atomic commits
• A collection of modifications either goes
  into the repository completely, or not at all.
• In other words, a commit will either
  altogether succeed, or it will altogether fail.
• Each file and directory has a set of
  properties—keys and their values—
  associated with it.
• You can keep certain files from being
  written into the repository by setting the
  svn:ignore property to a string that
  matches the files you want to omit. Such
  files are said to be “unversioned.”
  Binary versus Character Data
• Subversion expresses file differences
  using a binary differencing algorithm,
  which works identically on both binary and
  character-based files.
• Both types of files are stored in
  compressed format in the repository.
• CVS treats these file types differently.
    The Fundamental Problem
• User A gets a copy of file X from the data
• User B gets a copy of file X from the data
• User A changes X and writes the new X
  back into the data store.
• User B changes his older version of X and
  writes this into the data store, over-writing
  A’s changes.
• The lock-modify-unlock solution to the
  fundamental problem has several problems:
• Two users may want to modify two separate
  parts of the file, which means one user must
• After locking a file, the user may forget to unlock
• Locking does not solve incompatibility problems
  between separate files. (See subversion book
  for details.)
• Subversion uses a copy-modify-merge approach instead of locking.
• User A gets a “working copy” of X.
• User B gets a “working copy” of X.
• User A changes his working copy of X.
• User B changes her working copy of X.
• A saves his copy of X into the repository.
• B tries to save his copy of X into the repository, but it fails, because
  her changes were made to a now stale version of X
• B performs an “update,” which results in A’s changes to X to be
  merged into B’s version of X.
• If A’s changes do not conflict with B’s changes, the update silently
  completes. If A’s changes conflict with B’s changes, subversion
  inserts annotation into X describing the conflicts and then reports the
  problem to B. B then manually resolves the conflict.
• Whether B needed to manually resolve conflicts or not, the next step
  is for B to commit her changes into the repository, which now
 Copy-Modify-Merge in Practice
• With copy-modify-merge, users do not wait
  on each other.
• In practice, conflicts are rare and are
  usually straightforward to resolve.
• Copy-modify-merge does not work well
  with binary files, because changes can not
  be merged. For this reason, subversion
  provides a lock-modify-unlock process
  when needed.
• Subversion transactions are atomic: they
  either succeed entirely or fail entirely
• After the repository is initially created, it is
  an empty folder and has revision number
• After committing to a repository with
  revision number n, the repository is
  changed to version n+1.

This diagram and the following text were taken from the online
version of the Subversion book.

      When Subversion users talk about “revision 5 of foo.c”,
      they really mean “foo.c as it appears in revision 5.”
 Revisions and Working Copies
• Working copies do not always correspond
  to any single revision of the repository;
  they may contain files from several
  different revisions.
 Revisions and Working Copies
• User A checks out repository repo.
  repo/system.h   3
  repo/system.cpp 3

• User A modifies system.h and commits this file.
  repo/system.h   4
  repo/system.cpp 3

• User B commits changes to system.cpp, and A updates.
  repo/system.h   5
  repo/system.cpp 5
       States of a Working File
•   Unchanged, and current
•   Locally changed, and current
•   Unchanged, and out-of-date
•   Locally changed, and out-of-date
          Update and Commit
                       update            commit

Unchanged, and     does nothing      does nothing
Locally changed,   does nothing      writes changes
and current                          into repo
Unchanged, and     replaces working does nothing
out-of-date        file with new one
Locally changed,   merges changes operation fails
and out-of-date    into working file with out-of-date