Version Control with Subversion

1. Version Control with Subversion Quick Reference of Subversion

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

3. What is Version Control? • 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

4. Workflow Without 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.

7. Some Definitions • Repository – the place (can be server or location on hard drive) that the “master” files are stored. Managed by Subversion • The repository is a centralized store for data: • Stores data in form of a filesystem tree • Provides read/write access to the stored data • Remembers any modification made to it

8. Some Definitions • Working Copy – a “checked out” code you make your changes in • Users edit their working copy locally. • Changes are then committed to the repository. • After a commit, all other users can access the changes by updating their working copies to the latest revision.

9. Some Definitions • Commit – applying a change to the code on the repository • Update – downloading and merging all changes from repository into your working copy

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

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

12. How Working Copies Track the Repository • The working copy is made up of two parts: • a local copy of the directory tree of a project • an administrative directory named .svn in each directory, storing version control information • .svn is a hidden directory.

13. How Working Copies Track the Repository • Information stored in .svn directories: • For each file, Subversion stores: • the working revision of the file • a timestamp of the last update of the file • Given this information, by talking to the repository, Subversion can tell which of the following four states a working file is in: • Unchanged and current • Locally changed, and current • Unchanged, and out of date • Locally changed, and out of date

14. How Working Copies Track the Repository • Unchanged, and current • The file is unchanged in the working directory, and no changes to that file have been committed to the repository since its working revision. • An svncommit of the file will donothing, and • an svnupdate of the file will donothing. • Locally changed, and current • The file has been changed in the working directory, and no changes to that file have been committed to the repository since you last updated. There are local changes that have not been committed to the repository; thus • an svncommit of the file will succeed in publishing your changes, and • an svnupdate of the file will donothing.

15. How Working Copies Track the Repository • Unchanged, and out of date • The file has not been changed in the working directory, but it has been changed in the repository. The file should eventually be updated in order to make it current with the latest public revision. • An svncommit of the file will do nothing, • and an svnupdate of the file will fold the latest changes into your working copy. • Locally changed, and out of date • The file has been changed both in the working directory and in the repository. • An svncommit of the file will fail with an “out-of-date” error. The file should be updated first; • an svnupdate command will attempt to merge the public changes with the local changes. If Subversion can't complete the merge in a plausible way automatically, it leaves it to the user to resolve the conflict.

16. How Working Copies Track the Repository

17. What is TortoiseSVN • A very easy to use windows-integrated Subversion front-end • Makes your right click menus look like this…

18. Basic Commands on Windows

19. Revision • A revision is the state of the filesystem tree after a commit. • The state of the repository after each commit is called a revision. • To each revision, a natural number is assigned which identifies the revision uniquely. • Revision numbers always increase, starting from 0.

20. Revision • Revisions are assigned to the whole tree: a certain file can be left unchanged through different revisions • Files in the repository have always the same revision • Files in the working copy might have different revisions

21. Branches • A Branch is an independent line of development that shares a common history with another line of development • It begins life as a copy of something and moves on from there generating its own history

22. Branches • What are they good for? • Branches are usually used to try out new features without disturbing the main branch of development with compiler errors and bugs • As soon as the new feature of the branch is stable enough the branch is merged back into the main branch (the trunk) and removed

23. Tags • A tag is a snapshot of a project in time, E.g. each repository revision is a tag - a snapshot of the filesystem after each commit. • To make it easier to remember snapshots, Tags get human-friendly names like „release-1.0“. • Like Branches, Tags are created as copies of something • A tag is to save the state of a project that one later wants to refer to

24. Are Branches and Tags Diff? • No, not really. For Subversion Branches and Tags are the same • they are directories in the filesystem and handled in the same way. • Yes - From a user perspective • Branches are lines of development. That means, you make changes to them. • Tags are used to fixate a certain state of your development, so you should not commit to a Tag - although you could do that.

25. Repository Layout • Each Group has its own toplevel directory that only the team members have access to. Example: Project directory of group CI317 is http://206.180.209.64:8080/SVN/CISCourse/CIS31708FA • Within each of the group directories three subdirectories exist for software development: Trunk - Here the main development takes place Branches - Here you create Branches from Trunk Tags - Here you create Tags from Trunk

26. A quick run-through of subversion • 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

27. Import your code

28. Do the import • The URL is http://206.180.209.64:8080/SVN/CISCourse/CIS31708FA/ID

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

30. Checking out a Working Copy • Finished!! • The green check marks indicate two things: • the file is under subversion "control", and • that the file is equivalent to the most recently checked out version of the file (called the BASE).

31. Add a folder/file • Add the documents (to the local working space) • To add to repository, you need to • commit

32. Delete a folder/file • Delete some documents

33. Edit a file • Make an edit • Icons change on files

34. Commit changes • Nothing changes until you commit

35. Reverting (rollback) • If you have not committed • If you have committed

36. Comparing to old revisions • Right click > SVN >Diff

37. Comparing right before commit • Double click

38. View the logs

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

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

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

42. What to do.. • DO NOT COMMIT TO REPOSITORIES THAT YOU DO NOT OWN UNLESS YOU HAVE TALKED WITH AN OWNER OF THAT REPOSITORY FIRST!!!

43. Basic Work Cycle • Update your working copy. • svn update • Make changes. • svn add • svn delete • svn copy • svn move • Examine your changes. • svn status • svn diff • Possibly undo some changes. • svn revert • Resolve conflicts (merge others' changes). • svn update • svn resolve • Commit your changes. • svn commit

44. 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 onlyTortoiseSVN (http://tortoisesvn.net/downloads) • http://svnbook.red-bean.com/