Version Control with Subversion Quick use setup of Subversion in TAGD

What is Version Control? An alternative to sending zipped source code back and forth by email and manually integrating changes between more than one person “Version Control” is meant to solve the following problems: Users editing the same file concurrently overwriting each other Keeping users sharing the same source code that is in constant change in sync Keeping a running history of changes (and who did them) Recovering from disastrous changes in source code Is WONDERFUL for group work (and is an industry standard!) Also called “Source Control" Subversion aims to be a simple to use, secure, and safe way to do Version Control

Workflow Without Source Control

Workflow with Source Control

Benefits Group Work Group and Individual Work No zipping/unzipping from emails Manually merging is very rare Might be the only solution when you have more than 2 or 3 participants Group and Individual Work History of changes Sync when using multiple computers Easy backup

Requirements If you can develop on it, you can run subversion on it Can be configured to run on standalone custom server (easy), apache (advanced but featureful), or local on file system. TAGD provides free repositories on request

Some Definitions Repository – the place (can be server or location on hard drive) that the “master” files are stored. Managed by Subversion Working Copy – a “checked out” code you make your changes in Commit – applying a change to the code on the repository Update – downloading and merging all changes from repository into your working copy

Some more definitions Changeset – refers to a “commit,” is a list of files touched during that commit. Every changeset is ordered starting from 1 to however many commits there have been Conflict – When a user edits and commits a file while another user is editing the same lines. The second user can’t commit until he manually merges the conflicting lines. Rarely happens and is avoidable!!

What is Subversion? Robust, easy, and popular implementation of Version Control Very similar but “better” than CVS (a popular older Version Control System Everything is versioned (including renames and file meta-data) Atomic Commits (never a bad partial commit!) Many deployment options Well documented Named “SVN” for short http://subversion.tigris.org/

What is TortoiseSVN A very easy to use windows-integrated Subversion front-end We use it a lot at TAGD Makes your right click menus look like this…

A quick run-through of subversion Make a new repo on our hard drive Import our existing code to the repo Check out a working copy Make changes Add a file/folder Remove a file/folder Edit a file Commit Revert Comparing

Create a Repo Make a new folder, right click, svn > create Use FSFS Generally better to use over a network (but that’s out of scope for this tutorial) Repository over network can be provided by TAGD

My stuff is here

Import your code

Do the import The URL is file:///[where you made it] URL will be provided if you request a repository

Check out your working copy Make a folder, right click on it, choose “checkout” Fill in the URL

Add a folder/file Add the documents Delete some documents

Edit a file Make an edit Icons change on files

Commit changes Nothing changes until you commit

Reverting (rollback) If you have not committed If you have committed

Comparing to old revisions Right click > SVN > Diff

Comparing right before commit Double click

View the logs

Avoiding Conflicts Commit Often! Commit in small chunks! The less time you spend with code you havn’t committed, the less likely someone will edit a line you’ve not committed. Commit in small chunks! The less code you change and don’t commit, the less likely someone will edit a line you’ve not committed. Split your project into more than one file! You should be doing this anyways 

What not to do… Don’t commit broken code If someone else updates, they will have broken code too and will be unable to work unless they fix your mess Don’t commit temporary/binary files We don’t need files like vore.vcproj.SNOWFIRE.philipd.user or any .exe or .obj files. They waste space! You MAY commit graphics as long as they aren’t too big. Binary files don’t get merged. Don’t commit ginourmous files Remember, if you put it in the repository you force people to download it! A good alternative for optional files that are big is to put them on a web server – particularly if they don’t change

What to do.. When you commit, describe in the log as succinctly and clearly what you changed as possible This information will help others know what you did to the code Add your new files If you make a new file, make sure to right click and add it to source control. If you don’t, others won’t be able to get it. EXAMPLE: In a game, you add a bitmap file. If you forget to add it to the subversion, when others synchronize, they download your code but not the bitmap. Now when they run the game, it crashes because it can’t find your file.

DO NOT COMMIT TO REPOSITORIES THAT YOU DO NOT OWN UNLESS YOU HAVE TALKED WITH AN OWNER OF THAT REPOSITORY FIRST!!! I’ll break your arm off

Getting the Software If you are hosting (or downloading with command line) you will need Subversion(http://subversion.tigris.org/project_packages.html) If you are using under windows you will need only TortoiseSVN (http://tortoisesvn.net/downloads)

TAGD BigGame Repository Create a new folder Right click, check out Trac URL: http://tagd-dev.cs.tamu.edu/vore/ Don’t forget the trailing “/”