Subversion: Source Code Control
Computer Science and Engineering  The Ohio State University
 Widely used, especially in the
opensource community, to track all
changes to a project and allow access
 Can work across networks
 Key Idea: Repository
 The place where the originals and all the
modifications to them are kept.
 Each person “checkout”s their own,
private copy
 Changes are “commit”ed by each person
 Everyone else’s changes are “update”d
into your own copy.
Motivation
Computer Science and Engineering  The Ohio State University
 Team-based development
 Developers share and extend common code base
 Team members comply with standards (coding
conventions, comment templates,…)
 Bug fixes applied to deployed version 1.0 while
development continues, in parallel on version 2.0
 Especially important for Agile methods
 Popular for open source development
 But every team project needs some kind of code
management and versioning system
Key Idea: The Repository
Computer Science and Engineering  The Ohio State University
Fred
Repository holds master
copy of all files
 Never edited directly
 Stores history too
Developers have local
commit
repository
update
update
commit
Ayesha
copy in their own
workspace
 All work occurs here
Update:
 Bring local copies up to
date with repository
Commit:
 Send local edits to
repository
Conflicts and Merging
Computer Science and Engineering  The Ohio State University
 Optimistic team model
 Anyone can modify any file any time (no locking)
 Most edits can be safely merged automatically
 Assumption: real conflicts are rare Conflict: requires
attention
Fred
repository
Ayesha
update
commit

Merge
Error: working
version out-of-date
Tagging, Branching, and Merging
Computer Science and Engineering  The Ohio State University
 Repository is a tree of versions
 Development of main product occurs as a
series of revisions along trunk
 A tag names a particular revision
 Once tagged, a version is immutable
 Branches off of trunk or other
branches
 Bug fixes of a particular release
 Exploring different development paths
 Branches can be merged back to trunk
 Speculative direction pans out
A History of Revisions
Computer Science and Engineering  The Ohio State University
tag
1.0.1
merge
1.0
release
2.0
trunk
2.1
branch
2.0.1
2.0.2
maintenance
branch
Overview of Workflow
Computer Science and Engineering  The Ohio State University
Create and initialize the repository
 Once, by 1 person (done for this class for you)
 Check out the repository to your local directory
 Once (or many times), by each team member
 Create your files and add them to the repository:
 Once, by 1 person: Two members attempting to add
the same file can cause problems. Follow workflow
below.
 Synchronizing with the repository
 Repeated frequently by everyone







Update local files from repository
Run all unit tests
Make changes in local project files
Run all unit tests (make sure they pass!)
Update local files from repository and fix any conflicts
Add and Commit local files to repository
When to Update/Commit
Computer Science and Engineering  The Ohio State University
 Commit when confident that your work will
not break anything and commit often.
 Do not wait until perfection!
 Do make sure your new version compiles!
 Update before committing
 Integrates everyone else’s changes
 Update when you are ready for someone
else’s work
 Availability of new modules that may affect your
code
Best Practices: Golden Rule
Computer Science and Engineering  The Ohio State University
 Never break the build
 Applies (primarily) to trunk, although
breaking a multi-developer branch is
almost as bad
 Frequent commits are a good thing, but
partial code should not prevent another
developer from building and testing their
modifications
 (Almost) Never break a test case
 Other developers may think their (local)
changes are responsible for new errors
when they next update
Best Practice
Computer Science and Engineering  The Ohio State University
 Place in the Repository
 All source code written by the team.
 All resources needed by the team
 It is wise to place these in a separate top-level directory.
These resources can be large and slow down the update
process.
 Do not place in the Repository
 Generated code (.obj, .exe)
 Compile and Visual Studio files (.suo, .ncb).
 Other dependencies (not a strict rule, but use sense
and treat these as resources above.)
Best Practices: Process
Computer Science and Engineering  The Ohio State University
 Daily build schedule
 The “heartbeat” of the project
 Release means: tag + create branch for
maintenance
Pitfalls
Computer Science and Engineering  The Ohio State University
 Incomplete commits
 Common problem: forgetting to add a new
file
 Professional shops will have an automated
build process before committing.
 You can use the export command to test.
 System clock synchronization
 UTC, so no time zone issues
Shortcomings
Computer Science and Engineering  The Ohio State University
 Binary files have no meaningful diffs
 .pdf, .doc, .jpg
 Slow for large binaries
 large binaries/executables can be
provided outside the repository
Subversion tools
Computer Science and Engineering  The Ohio State University
 http://tortoisesvn.net/
 Tortoise SVN Tutorial video
 Additional tips and advice
 Short list of steps to set up your copy
of the project
 For step 2, you’ll need the address for
your team’s project (will be sent via
email)