1. Version Control with Subversion
Quick use setup of Subversion in TAGD

2. What is Version Control?
An alternative to sending zipped source code back and forth by 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

3. Workflow Without Source Control

4. Workflow with Source Control

5. Benefits Group Work Group and Individual Work
No zipping/unzipping from s
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

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

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

8. 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!!

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

10. 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…

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

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

13. My stuff is here

14. Import your code

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

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

17. Add a folder/file
Add the documents
Delete some documents

18. Edit a file
Make an edit
Icons change on files

19. Commit changes
Nothing changes until you commit

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

21. Comparing to old revisions
Right click > SVN > Diff

22. Comparing right before commit
Double click

23. View the logs

24. 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 

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

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

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

28. Getting the Software
If you are hosting (or downloading with command line) you will need
Subversion(
If you are using under windows you will need only TortoiseSVN (

29. TAGD BigGame Repository
Create a new folder
Right click, check out
Trac URL:
Don’t forget the trailing “/”