1. 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. Subversion: Source Code Control

2. Computer Science and Engineering The Ohio State University Motivation  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

3. Computer Science and Engineering The Ohio State University Key Idea: The Repository  Repository holds master copy of all files Never edited directly Stores history too  Developers have local copy in their own workspace All work occurs here  Update: Bring local copies up to date with repository  Commit: Send local edits to repository Ayesha Fred repository commit update

4. Computer Science and Engineering The Ohio State University Conflicts and Merging Fred Ayesha repository update commit  Optimistic team model Anyone can modify any file any time (no locking) Most edits can be safely merged automatically Assumption: real conflicts are rare Error: working version out-of-date Conflict: requires attention Merge

5. Computer Science and Engineering The Ohio State University Tagging, Branching, and Merging  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

6. Computer Science and Engineering The Ohio State University A History of Revisions trunk 1.0 1.0.1 2.0 2.0.12.0.2 branch maintenance branch tag release merge 2.1

7. Computer Science and Engineering The Ohio State University Overview of Workflow  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

8. 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 When to Update/Commit

9. Computer Science and Engineering The Ohio State University Best Practices: Golden Rule  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

10. Computer Science and Engineering The Ohio State University Best Practice  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.)

11. Computer Science and Engineering The Ohio State University Best Practices: Process  Daily build schedule The “heartbeat” of the project  Release means: tag + create branch for maintenance

12. Computer Science and Engineering The Ohio State University Pitfalls  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

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

14. Computer Science and Engineering The Ohio State University Subversion tools  http://tortoisesvn.net/ http://tortoisesvn.net/ Tortoise SVN Tutorial video  Additional tips and advice Additional tips and advice  Short list of steps to set up your copy of the project 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)