Version Control with Subversion

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

3. Workflow Without Source Control

4. Workflow with Source Control

5. Benefits • Group 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

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 • http://subversion.tigris.org/

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 yourequest 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! • 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(http://subversion.tigris.org/project_packages.html) • If you are using under windows you will need only TortoiseSVN (http://tortoisesvn.net/downloads)

29. 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 “/”