Version Control and SVN ECE 297

Why Do We Need Version Control?

3 What’s the Problem? (1) edits builds prog.exe tests File1.cpp File2.cpp File1.h File2.h What if prog.exe is now broken? What if you made many changes before figuring out it was broken? 1. Need a way to go back to a previous version of the program

4 Any Simple Solution? Maybe just make a copy of all the files really often Then switch to a backup copy whenever you do something wrong Problems: –How often will you copy all the files? Every 5 minutes? Could get big! –If something goes wrong, how will you know which backup copy you should go back to  you may have thousands! –Will you forget/get bored and not back-up the files for a while (a day? a week? a month?)

5 What’s the Problem? (2) edits builds tests File1.cpp File2.cpp File1.h File2.h edits prog.exe What the? Batman overwrote my changes! 2. Need a way to prevent conflicting edits to a file saves

6 Any Simple Solution? Maybe call or other developers whenever you start editing a file –“Nobody edit file1.cpp  I’m editing it” Then send another when you’re done –“OK to edit file1.cpp again” Many problems –I didn’t read the –We both send about file1.cpp at the same time –Won’t scale to many developers

7 What’s the Problem? (3) edits builds tests File1.cpp File2.cpp File1.h File2.h edits prog.exe Ugh! Half complete Batman stuff is in my tests! 3. Need to control when our changes become visible to others saves

The Solution: A Version Control System Our choice: Subversion (aka SVN)

9 Key idea: local copies, global master Tony’s working copy Bruce’s working copy svn repository svn commands to interact svn commands to interact

How Does this Solve Problem 3? Controlling when my changes become visible to others and their changes become visible to me

11 Problem 3: Control When Others’ Changes Visible svn repository builds tests prog.exe builds tests prog.exe Work on your own (working) copy. Change, build, test with no interference from others

12 Problem 3: Control When Others’ Changes Visible svn repository svn commit When your changes are finished and fully tested, commit them to the central repository (like publishing them)

13 Problem 3: Control When Others’ Changes Visible svn repository svn update Get all committed changes from others when it is a natural / convenient  usually when you’ve already committed all your changes and want to start working on something new

14 Problem 3: Control When Others’ Changes Visible svn repository svn update Some chance that your changes plus those of others don’t work together builds tests prog.exe builds tests prog.exe  Always re-build and re-test right after an SVN update Fix any integration errors / bugs right away svn commit & svn update frequently -- many small integrations easier to debug than one huge one

How Does this Solve Problem 1? Need to be able to go back to a previous version of the program

16 Problem 1: Revision History & Reverting Changes svn repository svn commit Each commit creates a new revision  older versions of the program still exist r1 r2 r3

17 Problem 1: Revision History & Reverting Changes svn repository r1 r2 r3 Last revision is called head revision By default, svn update updates your files to match it svn update

18 Problem 1: Revision History & Reverting Changes svn repository r1 r2 r3 svn update builds prog.exe tests Tests fail: I blame Batman!

19 Problem 1: Revision History & Reverting Changes svn repository r1 r2 r3 svn update -r 2 builds prog.exe tests OK now  Batman and tell him to fix his committed code

20 Problem 1: Revision History & Reverting Changes o svn repository r1 r2 r3 svn log What went wrong? or Netbeans: search history Shows list of files modified by every commit, and message for each commit  make these messages meaningful!

21 Problem 1: Revision History & Reverting Changes o svn repository r1 r2 r3 svn diff –r2 file2.cpp What went wrong? Can see what the change was to file2.cpp in revision 2. Maybe it was Tony’s bad? Netbeans: much easier to use; just click on what diff you want Can use svn revert to back out of bad changes (working copy or committed)

22 svn diff (Using NetBeans)

23 Doesn’t This Still Take Lots of Storage? No, only changes stored between revisions Even for huge programs, changes between revisions are small –If you are using svn properly and committing often!

How Does this Solve Problem 2? Prevent Conflicting Edits to a File by Different People

25 Two Basic Approaches Lock-based –Don’t let two people work on the same file at the same time –Used by older systems (rcs, pvcs) –Friends don’t let friends use these systems! Merge-based –Many people can modify the same file independently in their working copies –Sort out what to put in the repository only when each person commits –Used by modern / good systems (svn, git)

26 Problem 2: Conflicting Edits svn repository svn commit r1 r2 “working copy is out of date” based on r1

27 Problem 2: Conflicting Edits svn repository svn update r1 r2 based on r1 builds tests prog.exe based on r2

28 Problem 2: Conflicting Edits svn repository r1 r2 based on r1 based on r2 svn commit r3

29 What If Two People Modified the Same File? svn repository r1 r2 based on r1 svn commit “working copy is out of date”

30 What If Two People Modified the Same File? svn repository r1 r2 based on r1 svn update Each modified different lines  all OK! svn merges changes automatically

31 What If Two People Modified the Same File? svn repository r1 r2 based on r1 svn update What if some lines in same file were modified by 2 people? conflict: you must tell svn how to resolve svn resolve or NetBeans GUI (much easier!)

32 NetBeans Merge Tool Pick which version you want for conflicting lines Can also directly edit the merged file Once conflicts are resolved (you have made a merged file), you can svn commit To minimize conflicts, try to divide work between team members so you are usually working on different things (different features  different files or file sections)

33 SVN Workflow Overview Once for milestone0 Once per team for milestone1 Once per team member for milestone1 2 Many, many times!

Branching More Advanced Feature Not Required for this course but may be useful

35 Branching Tony Stark is finishing off milestone 1 –Working, he’s just fixing a few last bugs Bruce Wayne wants to start work on milestone 2 –But we don’t want him breaking anything now  not much time to fix for milestone 1 submission! Solution: branch

36 SVN Branching SVN commands svn copy repos/proj/trunk repos/proj/m1_branch svn checkout repos/proj/m1_branch … work normally … Tony now working on the branch r101 r100r99 r102 r103 r104 trunk (for m2) repos/proj/trunk branch (for m1) repos/proj/m1_branch r105 r106 Nothing special about these names; just two lines of development now root directory of the main (trunk) code  original repo in our case new copy of all files in repository  use for branch Set your working copy to the branch Time

37 Bug fixes on Trunk and Branch The more the trunk and branch code have diverged the higher the probability of conflicts and manual effort with svn merge r101 r100r99 r102 r103 r104 trunk (for m2) repos/proj/trunk branch (for m1) repos/proj/m1_branch r105 r106 key bug fixed  want to fix on trunk too! Use svn merge command r107 svn merge

38 Releasing Large Software Systems  Stabilization and review on branch  Before you release the final executable to customers  Don’t want new features coded & integrated during this time  New development goes on trunk  Can work/commit changes (revisions) to either branch or trunk  Parallel evolutionary paths for the software How early to branch? –Sooner: more time for stabilization –But you have to fix bugs in two places –Altera: branch 3 months before release Gives a long time to stabilize But extra work to fix bugs found in branch in 2 places for 3 months My preference: branch late –Less time for stabilization, but less duplicate work

39 References 297 svn quick start guide –Read it all and do the embedded tutorial –Don’t need to read for this course, but useful detailed reference