Version Control using Subversion

1
Version Control using Subversion

• Albert Young-Sun Kim
• November 2nd, 2005
• Available at http//www.stat.washington.edu/albert
  /presentations/2005-11-02-subversion/

2
Why use version control?

• Manage file sharing(Specifically Prevent
  people from erasing each others modifications)
• Keep past versions of files/directories
• Other benefits not relevant to us

3
1. At the Heart of SubversionThe Repository

• Typical Client/Server System
• The Repository is a kind of file server.
• However, Subversion remembers every change ever
  written to it!

4
The Problem of File Sharing

• We want to avoid the following scenario
• Overwriting each others modifications

5
One Solution Lock-Modify-Unlock

• Only one person may modify a file at any time.
• While this occurs, others can read the file, but
  not write to it

6
Problems with Lock-Modify-Unlock

• Can cause unnecessary delays (Say Harry forgets
  to unlock his file before going on vacation)
• Even more unfortunate if Harry and Sallys
  changes dont overlap

7
Better Solution Copy-Modify-Merge
Subversion does this!
8
Notes on Merge

• When changes dont overlap, merge is automatic
• When they do overlap, this is called a conflict.
  There are methods to efficiently handle this.
• May seem chaotic, but conflicts are rare and the
  time it takes to resolve conflicts is far less
  than the time lost by a locking system.
• (Assuming good communication between users, of
  course!)

9
Access

• Repository can be accessed
• Via file// serverEasiest for us (since were
  all on Madrid)
• Via http// serverRequires in-depth knowledge of
  Apache
• Via svn// serverEasiest across network access
• Via svnssh//Same as svn//, but more secure

10
2. Working Copies

• A Subversion working copy is an ordinary
  directory containing checked-out copies of
  files/directories in the repository
• Your working copy is your own private work area
• Subversion will never incorporate other people's
  changes, nor make your own changes available to
  others, until you explicitly tell it to do so

11
3. Revisions

• Each time the repository accepts a commit, this
  creates a new state of the filesystem tree,
  called a revision.

Each revision is assigned a unique natural
number, one greater than the number of the
previous revision
12
Importance of Revisions

• We can refer to past versions of files dirs
• By revision number svn diff r 34
• By keyword svn log -revision HEAD
• By dates svn checkout r 2002-06-22
• Revisions are our time machine!

13
Revision Keywords

• HEAD Latest revision in repository
• BASE The pristine copy of the working copy
  (i.e. when checkout was done)
• COMMITTED The last revision in which item
  actually changed (or at BASE)
• PREV The revision just before last revision in
  which an item changed (COMMITTED-1)

14
4. Getting Started

• Create repository
• Import initial files and directories to
  repository
• Initial checkout in order to obtain a working
  copy
• Basic Work Cycle

15
5. Basic Work Cycle

• (Also most common commands)
• Update your working copy
• svn update
• Make changes
• svn add
• svn delete
• svn copy
• svn move
• Examine your changes
• svn status
• svn diff
• svn revert

16
5. Basic Work Cycle

• Merge others changes
• svn update
• svn resolved
• Commit your changes
• svn commit
• (Optional) Examining History
• svn log
• svn list
• svn cat

17
a) Update your working copy

• svn updateBrings your working copy in sync with
  the latest revision in the repository

18
b) Make changes

• svn add
• svn delete
• svn copy
• svn move
• All these commands are on used on files and
  directories in the repository. Use these instead
  of standard UNIX commands mv, rm, etc

19
c) Examine your changes

• svn status (used the most)Compares status (up
  to date, out of date, etc) of working copy to
  latest revision in repository
• svn diffCompares the difference between working
  copy and latest revision in repository
• svn revertUndo any changes done to working copy
  (i.e. revert back to latest revision in
  repository)

20
d) Merge others changes

• svn updateSeen in a)
• svn resolvedUsed to declare all conflicts have
  been resolved

21
e) Commit your changes

• svn commitCommit the working copy to the
  repository. (i.e. check-in a new revision in
  repository)

22
f) (Optional) Examining History

• svn logShow record of all changes (not the
  actual changes) done in repository
• svn listShow a list of all files and directories
  in repository
• svn catExamine/Obtain an earlier version of a
  file or directory

23
More Detailed Explanations

• More detailed explanations of the previous
  commands of the Basic Work Cycle can be found in
  Chapter 3 of The Subversion Book found online.
• Particularly the notes on conflict resolution.
• Pages 19-41 of the pdf version
  http//svnbook.red-bean.com/en/1.1/svn-book.pdf

24
6. References

• Collins-Sussman, B., Fitzpatrick, B.W., Pilato,
  C.M. (2005). Version Control with Subversion (aka
  The Subversion Book)
• http//svnbook.red-bean.com/
• Notes Only the first 3 chapters are relevant to
  us.
• Chapter 1 includes a quick start guide, Chapter
  2 discusses the philosophy of Subversion and
  Chapter 3 is a guided tour of the basic commands
• Mason, M. (2005). Pragmatic Version Control
  Using Subversion. Pragmatic Bookshelf.
• Notes This book explains Subversion/Version
  Control from a programmers point of view.
  Available at UW libraries.