2. Version Control *Slides are modified from Prof. Necula from CS169

3. Outline What is version control? – And why use it? –Scenarios Basic concepts –Projects –Branches –Merging conflicts Systems –CVS –Subversion

4. All Software Has Multiple Versions Different releases of a product Variations for different platforms –Hardware and software Versions within a development cycle –Test release with debugging code –Alpha, beta of final release Each time you edit a program

5. Version Control Version control tracks multiple versions In particular, allows –old versions to be recovered (for comparison, tracking bug fixes, regressions) –multiple versions to exist simultaneously

6. Why Use Version Control? Because it is useful –You will want old/multiple versions –Without version control, can’t recreate project history Because everyone else does – An essential software development tool

7. Version Control Systems Numerous version control systems are available –Commercial (ranging from $100-$4000+ per user): ClearCase Microsoft Visual SourceSafe –Open-source – free: RCS (Revision Control System) SCCS (Source Code Control System) CVS (Concurrent Versions System) Subversion http://en.wikipedia.org/wiki/Comparison_of_revision_control_software

8. Architecture of a Version Control System Centralized repository serves multiple clients http://www.zefhemel.com/archives/2005/03/24/isdw-day-4-file-exchange

9. Scenario I – Fixing a bug First release of your project to your customer time Release 1.0

10. Scenario I – Fixing a bug Internal development, new releases to different customers time Release 1.01.3

11. Scenario I – Fixing a bug A bug is discovered in 1.0 release need to make a fix, but 1.3 is not ready for release to the customer. A new version of 1.0 is made with the bug fix Now there are two different development paths time Release 1.01.3 Bug fix for 1.0

12. Scenario I – Fixing a bug Apply the bug fixes on 1.3 and make new release with the bug fixes time Release 1.01.3 Bug fix for 1.0 1.4

13. Scenario II – Development Working on your project with your fellow developers time Release 1.4

14. Scenario II – Development Every developer checks out a copy of the code at version 1.4 Local versions isolate developers from interfering with each other. time Release 1.4 1.4.a 1.4.b 1.4.n

15. Scenario II – Development At the end of the day, developers check in their code to create the version 1.5 of the project The changes are now copied back to the version control system With every commit most organizations run a test suite to make sure that a checked in code doesn’t break the whole system. time Release 1.4 1.4.a 1.4.b 1.4.n 1.5

16. Scenario III – Debugging You develop a system through several versions. At version 1.5 you discover there is a bug in your system With version control you could checkout old versions of the system and find out in which version the bug was introduced. time Release 1.3 1.4 1.5

17. Concepts Projects Revisions Branches Merging Conflicts

18. Projects A project is a set of files in version control – Called a module in SVN Version control doesn’t care what files –Not a build system –Or a test system –Just manages versions of a collection of files

19. Revisions Lets assume a project with only one file Consider –Check out a file –Edit it –Check the file back in This creates a new version of the file –Usually increment minor version number E.g., 1.5 -> 1.6

20. Revisions - II Most edits are small For efficiency, don’t store entire new file –Store diff with previous version –Minimizes space –Makes check-in, check-out potentially slower –Must apply diffs from all previous versions to compute the current file Some systems have trouble with binary files –Store entire copies => inefficient

21. Revisions III With each revision, system stores –The diffs for that version –The new minor version number –Other metadata Author Time of check in Log file message Results of commit tests

22. checkoutupdatecheckindevelopment Ideal development with SVN repository Developer A Developer B

23. Merging Start with a file, say version 1.5 Alice makes changes A to 1.5 Bob makes changes B to 1.5 Assume Bob checks in first –Current revision is 1.6 = apply(B,1.5)

24. Merging II Now Alice checks in –System notices that Alice had checked out 1.5 –But current version is 1.6 –Alice has not made her changes in the current version! The system complains –Alice is told to update her local copy of the code Alice does an update –This applies Bob’s changes B to Alice’s code Remember Alice’s code is apply(A,1.5) Current version is 1.6 = apply(B, 1.5) Two possible outcomes of an update –Success –Conflicts

25. Merge - Success Assume that apply(A,apply(B,1.5)) = apply(B,apply(A,1.5)) Then order of changes didn’t matter –Same result whether Bob or Alice checks in first –The version control system is happy with this –Example: they both added a new method Alice can now check in her changes –Obtaining apply(A, 1.6) = apply(A, apply(B,1.5))

26. Merge - Failure Assume –apply(A,apply(B,1.5)) ≠ apply(B,apply(A,1.5)) There is a conflict –The order of the changes matters –Version control will complain –Example: they changed the method signature on the same method

27. checkin X Real development with SVN repository Developer A Developer B updateconflict resolution checkin conflict

28. Conflicts Conflicts arise when two programmers edit the same piece of code –One change overwrites another 1.5: a = b; Alice: a = b++; Bob: a = ++b; The system doesn’t know what should be done, and so complains of a conflict.

29. Conflicts are Syntactic Conflict detection is based on “nearness” of changes –Changes to the same line will conflict –Changes to different lines will likely not conflict Note: Lack of conflicts does not mean Alice’s and Bob’s changes work together

30. Example With No Conflict Revision 1.5: int f(int a, int b) { … } Alice: int f(int a, int b, int c) { … } add argument to all calls to f Bob: add call f(x,y) Merged program - Has no conflicts - But will not even compile

31. Don’t Forget Merging is syntactic Semantic errors may not create conflicts –But the code is still wrong –You are lucky if the code doesn’t compile Worse if it does... –Rare in practice, if you maintain good team communication Make it a habit to check status of files before doing a commit, to avoid unnecessary pain of merge clean up.

32. Subversion Details

33. Subversion Developed in 2000 and 2001 (by CollabNet, Inc.) to replace CVS and its shortcomings –Subversion is free –Subversion is open-source –Subversion operates across a network –Subversion handles any types of files, documents, or directories –Subversion requires administrative support http://svnbook.red-bean.com/

34. manages changes on a per file basis log messages for each change remote repository access tagging a set of files for later access invoked as svn from the command line

35. Subversion’s Storage Repository Subversion provides a centralized storage repository –Storage repository acts as a fileserver –Clients connect, then read from or write to files –Clients can also view logs of changes made to files or directories –All changes are logged, storing date, time, user responsible, user-specified notes

36. Basic Tasks administrative setup getting a working copy committing and understanding changes adding a file removing a file updating to the latest code

37. Getting a Working Copy get a new copy of the repository with: svn checkout where modulename is the name of the project you want to checkout svn checkout https://cengsvn.anadolu.edu.tr/svn/bim313/public/

38. Working Copies A Subversion working copy is an ordinary directory containing checked-out copies of files/directories in the repository Your working copy is your own private work area: Subversion will never incorporate other people's changes, nor make your own changes available to others, until you explicitly tell it to do so

39. Making Changes you make changes to your local copy and then commit them to the repository it is good form to make sure your changes compile before you commit

40. Reviewing & Committing Changes After appropriate changes, deletions, and additions have been made, you may commit your changes –SVN records your changes and associates them with a new revision number –Update the repository with all of your changes by performing a commit from the top-level folder svn commit

41. Importance of Revisions We can refer to past versions of files & dir’s: By revision number: svn diff –r 3:4 By keyword: svn log -–revision HEAD By dates: svn checkout –r {2002- 06-22} Revisions are our time machine!

42. Revision Keywords 1.HEAD : Latest revision in repository 2.BASE : The “pristine” copy of the working copy (i.e. when checkout was done) 3.COMMITTED : The last revision in which item actually changed (or at BASE) 4.PREV : The revision just before last revision in which an item changed ( COMMITTED-1 )

43. Viewing Changes to view the difference between your current file and the latest file in the repository: svn diff file for differences between your file and a some previous version X.Y: svn diff -r X.Y file to show record of all changes (not the actual changes) done in repository: svn log file to compare status (up to date, out of date, etc) of working copy to latest revision in repository svn status

44. Committing Changes Describe your changes for the revision log –Commit from the top-level folder –Every change that you commit goes down in history.... svn commit -m “Initial addition “

45. Updating to the Latest Code to update your working copy to the latest code in the repository: useful flags: –Areset any sticky tags/date/kopts –Pprune empty directories –dbuild directories, like checkout does svn update

46. Update Codes Mfile modified in your local copy Ufile brought up to date with repository ?file is in your local copy but not in the repository Ca conflict was detected between your local copy and the repository copy Afile is scheduled to be added to the repository Rfile is scheduled to be removed from the repository

47. Conflicts on Update your partners may have made changes that conflict with your changes –known as a conflict –C code on update edit the file to resolve the conflict commit only after you have resolved the conflict

48. Reverting Changes to revert a file in your local copy (based on version X.Y) to version W.Z in the repository: svn update -j X.Y -j W.Z file svn revert Undo any changes done to working copy (i.e. revert back to latest revision in repository) order matters directory and file renames cannot be reverted

49. Typical Workflows Update your working copy (i.e. your local repository): –svn update Change your working copy: –svn add –svn delete –svn copy –svn move –svn mkdir

50. Typical Workflows Review your changes: –svn status –svn diff –svn revert (undo) Resolve conflicts by merging: –svn update –svn resolved Commit your changes: –svn commit

51. Common Problems forgot to tag the repository –checkout by date –remember to unset the sticky tags svn checkout -D “YYYY-MM-DD HH:MM:SS” partners commit broken code –don’t let them –back out changes

52. Stuff We Didn’t Cover svn can keep track of multiple lines of development with the branches –there are subtle issues merging across branches –see the documentation for the whole story support for exclusive checkouts of files take arbitrary action on file commit

53. Common SVN Commands (1/2)‏ svn [svn-options] command [cmd-options] [files] add: svn add foo cat: svn cat svn://foo Examine/Obtain an earlier version of a file or directory checkout (co): svn co svn://host.com/dir/proj commit (ci): svn commit -m “log message” copy (cp): svn cp svn://foo svn://bar delete (rm): svn rm svn://foo diff: svn diff -r123 foo import: svn import svn://foo -m “import msg”

54. Common SVN Commands (2/2)‏ info: svn info list (ls): svn ls svn://foo Show a list of all files and directories in repository log: svn log foo Show record of all changes done in repository mkdir: svn mkdir foo move (mv): svn mv svn://foo svn://bar resolved: svn resolved foo Used to declare all conflicts have been resolved status: svn status -u update (up): svn up

55. Additional Recommendations Usage recommendations: –Avoid storing binary files or JARs Binary files use a lot of repository space –Avoid storing IDE-specific files e.g. do not store Eclipse or IntelliJ IDEA workspace or project files –Commit changes at meaningful checkpoints Frequently enough for others to share in development Infrequently enough so as not to create too many revisions

56. SVN online Official SVN site: http://subversion.tigris.org/ SVN tutorial: http://svnbook.red-bean.com/ SVN on Wikipedia: http://en.wikipedia.org/wiki/Subversion_(software)

57. References http://www.stat.washington.edu/albert/pres entations/2005-11-02- subversion/subversion.ppthttp://www.stat.washington.edu/albert/pres entations/2005-11-02- subversion/subversion.ppt http://cc.ee.ntu.edu.tw/~tianliyu/workshop/ svn-tut.ppthttp://cc.ee.ntu.edu.tw/~tianliyu/workshop/ svn-tut.ppt http://academic2.strose.edu/math_and_sci ence/goldschd/docs/2008-02- 29%20Subversion.ppthttp://academic2.strose.edu/math_and_sci ence/goldschd/docs/2008-02- 29%20Subversion.ppt