Version Control using Subversion Albert Young-Sun Kim November 2 nd, 2005 Available at entations/2005-11-02-subversion

Version Control using Subversion

Albert Young-Sun Kim

November 2nd, 2005

Available at http://www.stat.washington.edu/albert/pres

entations/2005-11-02-subversion/

Why use version control?

• Manage file sharing(Specifically: Prevent people from erasing each other’s modifications)

• Keep past versions of files/directories

• Other benefits not relevant to us

1. At the Heart of Subversion:The Repository

• Typical Client/Server System

• The Repository is a kind of file server.

However, Subversion remembers every change ever written to it!

The Problem of File Sharing

• We want to avoid the following scenario:

Overwriting each other’s modifications

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

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 Sally’s changes don’t overlap

Better Solution: Copy-Modify-Merge

Subversion does this!

Notes on Merge• When changes don’t 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!)

AccessRepository can be accessed:1. Via file:// server

Easiest for us (since we’re all on Madrid)

2. Via http:// serverRequires in-depth knowledge of Apache

3. Via svn:// serverEasiest across network access

4. Via svn+ssh://Same as svn://, but more secure

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

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

Importance of Revisions

We can refer to past versions of files & dir’s:

• By revision number: svn diff –r 3:4• By keyword: svn log -–revision

HEAD• By dates: svn checkout –r {2002-

06-22}

Revisions are our time machine!

Revision Keywords

1. HEAD: Latest revision in repository

2. BASE: The “pristine” copy of the working copy (i.e. when checkout was done)

3. COMMITTED: The last revision in which item actually changed (or at BASE)

4. PREV: The revision just before last revision in which an item changed (COMMITTED-1)

4. Getting Started

1. Create repository

2. Import initial files and directories to repository

3. Initial checkout in order to obtain a working copy

4. Basic Work Cycle

5. Basic Work Cycle:(Also most common commands)a) Update your working copy

• svn updateb) Make changes

• svn add• svn delete• svn copy• svn move

c) Examine your changes• svn status• svn diff• svn revert

5. Basic Work Cycle

d) Merge other’s changes• svn update• svn resolved

e) Commit your changes• svn commit

f) (Optional) Examining History• svn log• svn list• svn cat

a) Update your working copy

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

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…

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)

d) Merge other’s changes

• svn updateSeen in a)

• svn resolvedUsed to declare all conflicts have been resolved

e) Commit your changes

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

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

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

6. References1. 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

2. 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.