1. Copyright © 2015 – Curt Hill Version Control Systems Why use? What systems? What functions?

2. What are they? Software that stores different versions of documents –Documents are usually source code –May also include auxiliary items: Test cases Documentation Make files Allow developers to recreate the way the system was at a previous time –Somewhat like an editor undo but much larger and more complicated Copyright © 2015 – Curt Hill

3. Problems That are Solved Program is updated but the fix broke something else –Cannot find all the places changed to restore to original state –Problem not detected until much later Two people make changes to a program –Both changes work alone –When put together it does not work Copyright © 2015 – Curt Hill

4. Versions Often refers to a succession of the same program –Windows 7 and 8 are different versions May also refer to different targets –Linux for Intel vs. Linux for ARM –Lots in common but differences in various places Copyright © 2015 – Curt Hill

5. What do they do? Keep multiple versions of any relevant documents Maintain information about changes –Who made the change –Comments on what the change did –Dates of the versions Allows code to be checked out, changed and then checked back in Show differences between two files Copyright © 2015 – Curt Hill

6. What not to keep? Anything that can be generated: Object or machine language –Generated by compilers Documentation that is machine generated by: –JavaDoc –Doxygen –Any other document generator Anything else that can never change Copyright © 2015 – Curt Hill

7. The Process A repository keeps the documents –Very specialized database Developer checks out a document This is edited to improve it It is checked back in (aka committed) with the control information If the repository supports: –Automatic unit tests are run –Failure of these can retract the check in Copyright © 2015 – Curt Hill

8. Terminology Version – updated copy of a document Branch – new target of a document –Versions are automatically created, but branches are not –Allows multiple current documents Merge – making two branches into one Project – a set of files pertaining to one program or system Conflict – a check in of two items that do not agree Copyright © 2015 – Curt Hill

9. First Branch Support The C preprocessor was the first attempt to handle multiple platforms This uses the #if, #ifdef, #ifndef etc. Code specific to a single hardware or compiler could be incorporated without separating into two separate files –The separate files will defy proper maintenance Copyright © 2015 – Curt Hill

10. Example Branch Version 1.0 is released Version 1.1 is an improvement Before 1.1 is ready for release a problem is found and a bug fix generated –Create 1.0.1 We now have a branch of 1.1 and 1.0.1 Copyright © 2015 – Curt Hill

11. A Branch Copyright © 2015 – Curt Hill 1.01.1 1.0.1

12. Example Merge Two branches –1.1 is still under development –1.0.1 is stable Version 1.1 has some improvements which we do not want to discard What is needed is to merge the fix of 1.0.1 into 1.1 Copyright © 2015 – Curt Hill

13. A Merge Copyright © 2015 – Curt Hill 1.01.1 1.0.1 1.2

14. Example Again It is possible that the changes of 1.1 did not need the bug fix of 1.0.1 because it tried another approach to the same code –If so the 1.0.1 becomes a dead end and is not developed further The version numbers are likely to be maintained by the version control and more version numbers will be generated Copyright © 2015 – Curt Hill

15. Branching Again The branch before produced a dead end after the changes were merged with the developed new version Branches are often more permanent –One branch for Windows –One branch for Mac –Both will be continued indefinitely Copyright © 2015 – Curt Hill

16. Simultaneous Checkout Copyright © 2015 – Curt Hill 1.2 1.2a 1.2b Suppose two or more developers check out the same code in a day. What will happen on check in?

17. Several Options Some systems only allow the first check in –This will force the second one to reconcile the two sets of changes Some systems will accept both provided they do not touch any of the same lines Some will merge both and then run tests and reject them if they do not work Copyright © 2015 – Curt Hill

18. Check in Copyright © 2015 – Curt Hill 1.2 1.3 Top checked in first and retained. Bottom checks out 1.3 and then applies different changes. 1.4

19. Distributed Many of the older version control systems relied on a single repository –Easy to maintain, but only one disk error from disaster Distributed version controls are more robust but much more complicated Copyright © 2015 – Curt Hill

20. Distributed Again A distributed version control system has multiple repositories How are they kept synchronized? A push is a repository telling others about changes in a project A pull is a repository asking for updates from another Push/pull usually involves multiple files instead of single files Copyright © 2015 – Curt Hill

21. Systems SCCS RCS PVCS Subversion GIT Mercurial Many others Copyright © 2015 – Curt Hill

22. SCCS Source Code Control System UNIX May be first, no later that early 1970s Stored originals and then the differences between a version and the next version Copyright © 2015 – Curt Hill

23. RCS Revision Control System Update of SCCS, also on UNIX Keep current and uses differences to go back in time Copyright © 2015 – Curt Hill

24. CVS Concurrent Version System Update of RCS but operates on several types of systems Uses client / server approach Copyright © 2015 – Curt Hill

25. Subversion An update of CVS May apply versioning to directories and metadata –Not just files Atomic check-in –No overwriting Client Server model –Clients may be on different machines Copyright © 2015 – Curt Hill

26. SVN Architecture Copyright © 2015 – Curt Hill

27. GIT An open-source, distributed version control system –GITHUB seems to be the current choice for open source projects Developed by Linus Torvalds for the LINUX kernel Designed for speed and scalability Each developer gets a local copy of the repository Copyright © 2015 – Curt Hill

28. Mercurial Another open-source, distributed version control system with many similarities to GIT Copyright © 2015 – Curt Hill

29. Conclusions Version control is a requirement for software development Allows easy recreation of the project at a particular time –Which makes it easier to find when a bug was introduced Also supports branches –Different platforms or different functionality while still maintaining the common code base The check out and check in feature enables teams Copyright © 2015 – Curt Hill

30. Post Conclusions Lets see if we can examine some of these –Subversion –Git Copyright © 2015 – Curt Hill