The Design Workshop

1. The Design Workshop Introduction to Version Control

2. Agenda Introduction to Version Control Exercise 1: Project Initialization Exercise 2: Project Modification (Automatic Merge) Exercise 3: Project Modification (Manual Merge) Closing Comments

3. Motivation for Version Control The project based work requires several developers to access the same files at the same time, hence some sort of coordination is needed Several tools are available for this purpose, amongst others Subversion (SVN), which enables a group of developers to work seamlessly on a set of source files (if used properly) The Subversion architecture is a based on a centralized model, where the version control functions are performed on a shared server. A free hosting service is provided by Google, offering a Subversion interface • http://code.google.com/hosting/ An open source graphical client (tortoiseSVN) that integrates into Windows Explorer is available from • http://tortoisesvn.tigris.org/

4. Version Control Terminology Basic Setup • Repository: The database storing the files • Working Set/Working Copy: Your local directory of files, where you make changes. • Trunk/Main: The “primary” location for code in the repository. Think of code as a family tree – the “trunk” is the main line. • Head: The latest revision in the repo. Basic actions • Check out: Retrieve a copy of the project source from the repository • Update: “Resync” your local copy to reflect the development from the repository • Commit: “Push” your local modifications to the repository • Resolve Conflict: When two developers make contradicting modifications (same file, same line) the SVN server is not able to merge automatically, and a conflict appears. The developer needs to resolve this conflict (through a manual merge)

5. Example: The Grocery List An example is used for describing the concept. The life cycle of a text file describing the grocery list for a restaurant is tracked. Firstly, basic ingredients for existing menus are added to the grocery list producing new revisions of the file.

6. Example: The Grocery List At each modification the file is checked out, modified, and subsequently checked in. The modification could also be discarded by reverting to the previous version.

7. Example: The Grocery List The trunk has a history of changes as a file evolves. Diffs are the changes you made while editing: imagine you can “peel” them off and apply them to a file. For example, to go from r1 to r2, we add eggs (+Eggs). Imagine peeling off that red sticker and placing it on r1, to get r2.

8. Example: The Grocery List Branches let us copy code into a separate folder so we can modify it separately. For example, we can create a branch for new, experimental ideas for our list: crazy things like Rice or Eggo waffles.

9. Example: The Grocery List When merging back we only want to apply the changes that happened in the branch. That means we diff r5 and r6, and apply that to the trunk.

10. Example: The Grocery List Conflicts arise when contradicting modifications are merged. Joe wants to remove eggs and replace it with cheese (-eggs, +cheese), and Sue wants to replace eggs with a hot dog (-eggs, +hot dog).

11. Example: The Grocery List At this point it’s a race: if Joe checks in first, that’s the change that goes through (and Sue can’t make her change). When changes overlap and contradict like this, SVN reports a conflict and won’t let you check in – it’s up to you to check in a newer version that resolves this dilemma, coordinate with the other developer. Conflicts are infrequent but can be a challenge.

12. Example: The Grocery List Tags are principally just branches that you agree not to edit, which enables a tag (label) to be applied any revision for easy reference. This way you can refer to “Release 1.0″ instead of a particular revision.

13. Example: Life Cycle For the purpose of this workshop (and probably the next ones as well) branching and tagging is discouraged. Do all your development within the trunk, and thereby simplify the use of version control.

14. Agenda Introduction to Version Control Exercise 1: Project Initialization Exercise 2: Project Modification (Automatic Merge) Exercise 3: Project Modification (Manual Merge) Closing Comments

15. Prerequisites Server Side (Google Hosting) • Google Account (one per developer) Find your personal password from “Profile”  “Settings” when logged in • Software Project (one per group) Choose an “owner” that creates the project (choose Subversion as version control system) and adds the other group members from “Project Home”  “People” Project name ucn-workshop-design-dmXX-groupY (XX = class no, Y = group no) Client Side (TortoiseSVN) • TortoiseSVN (needs to be installed on each developers computer) • SCPlugin (Mac OS X variant – appears not to work flawlessly with OS X 10.6)

16. Checking out the Project When signed in (at Project Hosting) go to the project page and further to the Source tab. The URL of the project is in the form • https://<projectname>.googlecode.com/svn/trunk/ Use TortoiseSVN to check out the project, and add the above URL • Right click  “SVN Checkout…” and enter your credentials when requested Ensure all group members have checked out the project before proceeding

17. Adding Files to the Project One of the group members copies the framework files to the SVN folder (where the project is checked out) and right clicks all the files  “TortoiseSVN”  “Add…” 

18. Adding Files to the Project At the moment the files are only “marked for addition”, commit to push this modification to the repository (right click  “SVN commit”)

19. Distributing the Files The framework files should now be present at the repository, and all developers now need to “update” to achieve a working copy of the files. Make a new BlueJ project based on the files, and ensure that the two packages appear within the project.

20. Agenda Introduction to Version Control Exercise 1: Project Initialization Exercise 2: Project Modification (Automatic Merge) Exercise 3: Project Modification (Manual Merge) Closing Comments

21. Project Modification (Automatic Merge) The purpose of this exercise is to have two developers modify the same file, which is then automatically merged when subsequently committed to the repository. Each group is thus to be split in two – representing two developers refactoring source code independently of each other. Ensure that both developers share the same project revision • Update on both computers and check the revision number

22. Project Modification (Automatic Merge) The refactoring is now to begin from within the file “AddressCtr.java”: • Developer1 renames the method “createPerson” to “createPersonDeveloper1” • Developer2 renames the method “deletePerson” to “deletePersonDeveloper2” Developer1 now commits the modification to the repository, and developer2 discovers that an update is required before a commit can take place

23. Project Modification (Automatic Merge) At an update (by developer2), developer1’s modification is successfully merged into developer2’s local copy A subsequent commit (by developer2) will now create revision 8 within the repository, containing both modifications

24. Agenda Introduction to Version Control Exercise 1: Project Initialization Exercise 2: Project Modification (Automatic Merge) Exercise 3: Project Modification (Manual Merge) Closing Comments

25. Project Modification (Manual Merge) Once again, the purpose is to have two developers modify the same file, however now within the same line. SVN will not be able to merge this automatically, and a manual resolution is required. Once again ensure that both developers share the same project revision by comparing the revision information at the update procedure. The refactoring is now to begin from within the file “AddressCtr.java”: • Developer1 renames the method “createPersonDeveloper1” back to the original “createPerson”, and commits subsequently • Developer2 renames the method “deletePersonDeveloper2” back to the original “deletePerson”, and renames “createPersonDeveloper1” to “createPersonDeveloper2”, and attempts a commit (after the required update)

26. Project Modification (Manual Merge) As the two developers have modified the same file within the same line a conflict is to be created  right click the file and choose TortoiseSVN  “Edit Conflict” Mark as resolved when done Use blue arrows for the resolution Developer1’s modifications Developer2’s modifications Merge result

27. Project Modification (Manual Merge) Let us accept developer1’s modification (“use theirs”), and mark the conflict as resolved. To ensure subsequently that the conflict has been correctly resolved, right click (in explorer)  “TortoiseSVN”  “Check for modifications” The status should be “modified” and a sanity check can be made by “Compare with base”. The modification can now be committed, and we are back to square

28. Agenda Introduction to Version Control Exercise 1: Project Initialization Exercise 2: Project Modification (Automatic Merge) Exercise 3: Project Modification (Manual Merge) Closing Comments

29. Subversion Best Practices Always update before modification (working from the head of the development reduces the risk of conflicts) Avoid adding auto-generated files to SVN (conflict are likely to appear in the nature of things) During the initial trials of SVN usage, backup the local copy before interfacing the server Always test your modification prior to committing to the repository • Ensure a stable trunk – no one likes fixing other developers’ bugs! • Agree within the group upon a “quality gate” e.g. successful compilation or successful execution of a set of test cases When applying SVN commands work from the top level folder of the project to ensure that all modifications are committed

30. Subversion Best Practices … and probably the most important Prior to committing, do a “diff” on the changeset, to ensure only intended modifications are committed (or use the “Check for modifications” along the way)