Subversion Source Code Control Computer Science and Engineering

Subversion: Source Code Control Computer Science and Engineering The Ohio State University o Widely used, especially in the opensource community, to track all changes to a project and allow access Can work across networks o 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 o 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 o 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 o. Repository holds master copy of all files Never edited directly Stores history too o. Developers have local commit repository update commit Ayesha copy in their own workspace All work occurs here o. Update: Bring local copies up to date with repository o. Commit: Send local edits to repository

Conflicts and Merging Computer Science and Engineering The Ohio State University o 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 o Repository is a tree of versions Development of main product occurs as a series of revisions along trunk o A tag names a particular revision Once tagged, a version is immutable o Branches off of trunk or other branches Bug fixes of a particular release Exploring different development paths o 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) o Check out the repository to your local directory Once (or many times), by each team member o 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. o Synchronizing with the repository Repeated frequently by everyone o o o o 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 o 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! o Update before committing Integrates everyone else’s changes o 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 o 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 o (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 o Place in the Repository All source code written by the team. All resources needed by the team o It is wise to place these in a separate top-level directory. These resources can be large and slow down the update process. o 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 o Daily build schedule The “heartbeat” of the project o Release means: tag + create branch for maintenance

Pitfalls Computer Science and Engineering The Ohio State University o 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. o System clock synchronization UTC, so no time zone issues

Shortcomings Computer Science and Engineering The Ohio State University o Binary files have no meaningful diffs . pdf, . doc, . jpg o Slow for large binaries/executables can be provided outside the repository

Subversion tools Computer Science and Engineering The Ohio State University o http: //tortoisesvn. net/ Tortoise SVN Tutorial video o Additional tips and advice o 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)