1. SOFTWARE REVISION CONTROL WITH SUBVERSION Evan Dickinson & Andy Huang – 9 March 2011

2. About revision control  Revision control tracks the changes you make to your code  Professional software developers can’t live without it.  Worth knowing if you write code at all, even if you’re not a “software person”

3. What it’s good for  Offsite backup  Coordinate team work  See changes  Undo the change that broke everything  Freedom to experiment  You can always revert back to working code  Organization  Don’t have to e-mail files, or make lots of copies.

5. Why you might not use it (for now)  Learning takes (a bit of) time  You’re using MAX/MSP  Photoshop, Illustrator, and other media files also have low payoff.  Several features work best with text files, not graphics.  But other features are still valuable, even with graphic files.  Plan B: Dropbox  At least have a backup & central location for all code

6. About Subversion (svn)  There are several tools for revision control  subversion is one of them  svn is a command-line tool  several graphical front-ends available  Free GUI and free hosting:  SmartSVN (GUI – Mac, Windows, and Linux) Demo. Free version has limited features, but they’re good enough.  Assembla.com (hosting)

7. Installation  Will be covered later  It’s boring

8. Subversion Concepts

9. Repository  A server that stores your code  Repository records:  Every change that’s made  Who made it, when, and why  This is what assembla.com gives you  Except they call repositories “spaces.” It’s the same thing.

10. Working copy  A copy of the code on your laptop  What you edit when you’re writing code  You can have several working copies on your computer  Your teammates have their own working copies

11. 1 Repository & Many Working Copies Repository (assembla.com server) Clip art: all-free-download.com Evan’s Computer Two working copies, each in different folders Andy’s Computer One working copy

12. Revisions  When you get your code to a good stopping point, snapshot the change in a revision.  Share the code with your team  Gives a known-good point to go back to  Assembla also calls these “change sets”

14. Workflow Example

15.  Stop when the code does what you want it to, and you’re ready to share Step 1: Write your code

16.  Make sure you’re changing what you think you’re changing  Keep out temporary/testing changes  SmartSVN: “Changes” button.  Sometimes called “diff” Step 2: Review your changes

17.  Brings in newer changes (if any)  Keeps you from overwriting your team members’ changes.  SmartSVN: “Update” button Step 3: Update

18.  SmartSVN: “Commit” button  Write a message that describes what you changed Step 4: Commit the Change

19. Done: Now your change is in the repository

20. Demo

21. Working with other people Multiplayer Subversion

22. Workflow: Two people editing different files Evan’s Working CopyRepositoryAndy’s Working Copy Revision: 5 Edit foo.pdeEdit bar.pde Commit revision 6Revision: 6 Repository has Evan’s change to foo.pde Still at revision 5 Update to revision 6. Andy’s working copy has Evan’s change. Edit bar.pde some more Still at revision 6Revision: 7 Repository has Andy’s change to bar.pde Commit revision 7 Update to revision 7. Evan’s working copy has Andy’s change

23. Two people editing one file  Best to do this rarely:  I’m not saying “don’t” – sometimes you need to  Use good communication: Coordinate who’s doing what Avoid incompatible changes  But when you do:  You can’t accidentally overwrite someone else’s changes  When you do an update (to get new changes): Changes that don’t conflict are brought in automatically Conflicting changes are highlighted for you to fix (see the section Conflict Resolution)

24. Demo

25. Links and Resources  SmartSVN: http://www.syntevo.com/smartsvn/http://www.syntevo.com/smartsvn/  http://www.syntevo.com/smartsvn/documentation.html http://www.syntevo.com/smartsvn/documentation.html  Subversion: http://subversion.apache.org/http://subversion.apache.org/  Assembla: http://www.assembla.comhttp://www.assembla.com  Version Control with Subversion  Online book  http://svnbook.red-bean.com/ http://svnbook.red-bean.com/

26. Three steps: 1. Sign up for an assembla.com account 2. Install SVN client 3. Install SmartSVN Installation

27. Assembla.com  Register an account  Create a space  You want the free subversion repository  The free options are hidden – click to expand  http://www.assembla.com/catalog

28. Install SVN Client – Mac  Install the MacOS X developer tools  SVN is included  These are on the MacOS X install DVD  Also downloadable from http://developer.apple.com/technologies/tools/ http://developer.apple.com/technologies/tools/  Is svn already installed?  Open Terminal  Run: which svn

29. Install SVN Client – Windows  Download it from:  http://sourceforge.net/projects/win32svn/ http://sourceforge.net/projects/win32svn/

30. Install & Configure SmartSVN  Download from:  http://www.syntevo.com/smartsvn http://www.syntevo.com/smartsvn  When you run it for the first time, it will ask for paths to svnadmin and svnserve  Mac: /usr/bin/svnadmin /usr/bin/svnserve  Windows: c:\program files\subversion\bin\svnadmin c:\program files\subversion\bin\svnserve

31. Configure SmartSVN (part 2)  It starts by offering to set up a repository for you.  Say no. (That offer assumes your repository already has code in it.)  Instead, you want: Import Project Into Repository  This is on the welcome window, or File -> Import

32. SmartSVN: Import Project Into Repository  While importing into the repository, you’ll get to a step where it asks you which repository to import to.  This is where you tell SmartSVN about your assembla repository.  Add a new repository and fill in the details Here’s where you find the URL to use

33. A reminder of what all the buttons do SmartSVN Overview

34. Check the selected file If you select a directory, your action applies to all files in that directory. This is usually what you want. If you select one file, you only work with that one file. That can be bad if you wanted to commit all your files, but just commit one by mistake.

35. Refresh Load the latest data from the repository. Use this to see if there are newer revisions.

36. Update Two uses: 1.Grab the latest code from the repository. 2.Change the working copy to an older revision. (This is useful for figuring out if a problem you just found exists in older revisions.) Two uses: 1.Grab the latest code from the repository. 2.Change the working copy to an older revision. (This is useful for figuring out if a problem you just found exists in older revisions.)

37. Commit Send the contents of your working copy to the repository. None of the changes you make to your working copy are applied to the repository until you do a commit. Send the contents of your working copy to the repository. None of the changes you make to your working copy are applied to the repository until you do a commit.

38. Add Tells subversion to track changes to the selected file (or directory). Subversion only tracks the files you tell it to track. Files you don’t add won’t be in your repository. Tells subversion to track changes to the selected file (or directory). Subversion only tracks the files you tell it to track. Files you don’t add won’t be in your repository.

39. Remove Tells subversion stop tracking changes to the selected file (or directory). Old versions of the file will remain available in the repository. But the file will no longer be in new versions of the repository. Tells subversion stop tracking changes to the selected file (or directory). Old versions of the file will remain available in the repository. But the file will no longer be in new versions of the repository.

40. Move (and Rename) Move and/or rename a file. SmartSVN gets confused if you move/rename files from the Finder (or Windows Explorer) Move and/or rename a file. SmartSVN gets confused if you move/rename files from the Finder (or Windows Explorer) In this example, we’ve renamed Arm.pde to Leg.pde. Until you do a commit, Arm.pde will show up as “removed.”

41. Revert Throws away the changes you’ve made in your working copy. Reverts a file (or directory) back to the way it was when you did an update.

42. Delete Deletes a file. Only use this on files that are not tracked by subversion.

43. Changes Shows the changes you’ve made in the file.

44. Annotate Shows who wrote each line of the file, and when.

45. Log Shows the list of revisions

46. Fix and Graph These are advanced features. You don’t need them.

47. Conflict Resolution

48. Conflicts  Conflicts occur when two people make incompatible changes to one file at the same time.  Usually, it’s OK for two people to change the same file, as long as they change different parts of the file. But if the changes are too close together, they conflict.  Conflicts are rare. But if they happen to you, here’s what to do.  If you communicate with your team about who’s changing what, you can avoid conflicts in the first place.

49. What conflicts look like We did an update and – oh no! – there are conflicts. The new files are:.mine – the file you edited, as it was before the update.r3 – the predecessor for your changes. (That is, the file as it was before you started editing.) The number will be different in your case..r6 – the newest version of the file. We did an update and – oh no! – there are conflicts. The new files are:.mine – the file you edited, as it was before the update.r3 – the predecessor for your changes. (That is, the file as it was before you started editing.) The number will be different in your case..r6 – the newest version of the file.

50. Fixing conflicts The left pane shows your file, before the update. The center pane is the file where you’ll resolve the conflicts. Right now, it has both changes in it, which is no good. Bring up the conflict solver with Tools -> Conflict Solver The right pane shows the newest version in the repository. We got a conflict because two people changed the same line, at the same time.

51. Fixing conflicts, continued Use the Take Left and Take Right buttons to choose which code to use.

52. Fixing conflicts, continued Here, we used Take Right to copy the changes from the right-hand side to the middle. The conflict is now resolved, and we can save the file and commit it.