Version Control an Essential Tool for Collaborative Software Development
Total Page:16
File Type:pdf, Size:1020Kb
Version Control An Essential Tool for Collaborative Software Development Philipp Haller Associate Professor School of Electrical Engineering and Computer Science KTH Royal Institute of Technology DD2480 Software Engineering Fundamentals 17 January, 2020 About Myself • 2006 Dipl.-Inform. Open source activities: Karlsruhe Institute of • Member of Scala language Technology (KIT), Germany team 2006—2014 Creator of Scala’s first 2010 Ph.D. in Computer • • widely-used actor library Science Co-author of futures and Swiss Federal Institute of • promises in Scala Technology Lausanne (EPFL) • Co-author of Scala’s async/ await extension • Held positions at Typesafe, Inc., Stanford University, and EPFL • Since Dec 2014 at KTH A Large Open-Source Project • Example: Scala programming language • Many {users, contributors, commits, releases, …} Challenges of Collaborative Software Development • Several developers extending/changing the same code base concurrently • How to integrate multiple, possibly conflicting changes? • How to track ownership of changes to code and documents? • Development and maintenance of multiple major versions in parallel • Maintain previous major versions through bug fixes (e.g., v3.0 -> v3.1) • In parallel, develop new feature or next major version v2.1.4 -> v2.1.5, v2.1.x -> v2.2.0 • Unambiguous identification of a revision/stable release • Each revision of each file/directory/resource etc. Version Control • Version control = practices and tools that provide control over changes to source code and other documents • Synonyms: revision control, source control, software configuration management (SCM) What to keep versioned? Which source code, files and artifacts should be maintained using version control? YES, of course! • Current development version of source code? • Coding experiment but commented out? NO, comments should normally not be committed Compiled binaries (e.g., JVM .class files)? • NO! • Build files, build scripts (e.g., for Maven, Gradle, sbt) YES! • Documentation? YES! • Configuration files? YES! Basic Concepts (1) • Revision (or “version”) • The state of either (a) a single file, or (b) the entire source tree, at a given point in time • Repository - storage for current and historical state of all versioned files • Working copy - local copy of files from a repository at a specific revision Basic Concepts (2) • Commit • As a verb: “writing changes made in working copy back to repository” • As a noun: the revision created as a result of committing • Change set - set of changes made in a single commit • Branch, trunk - copy of source tree developed independently • Head (also tip) - most recent commit either to the trunk or to a branch History: 1st Generation • SCCS (Source Code Control System) - created in 1972 at Bell Labs • Tracks changes in source code, enables retrieving any of its previous versions • Known for the sccsid string: static char sccsid[] = "@(#)ls.c 8.1 (Berkeley) 6/11/93"; • RCS - first released in 1982 by Walter F. Tichy at Purdue University • Core concept: check-in and check-out of sets of files called revision groups • Revisions stored in a tree structure; can revert to previous revisions • DSEE (Domain Software Engineering Environment) • Predecessor of ClearCase developed by Atria Software History: 2nd Generation • CVS (Concurrent Versions System) Last release in 2008 • Originally developed as a front end for RCS • Before SVN the de-facto standard VCS in the open source world • Subversion (SVN) - added features missing in CVS • Commits as true atomic operations Interrupted commits of multiple files could lead to Renamed/moved files retain full revision history • corruption in CVS • Branching is a cheap operation • SVK - uses Subversion file system, adds features • Offline operations (checkin, log, merge); distributed branches History: 3rd Generation • Decentralized version control systems become mainstream • Improvements in speed, reliability and flexibility Decentralized Version Control Systems • Peer-to-peer approach: • Full history mirrored on every developer's computer • Repositories are synchronized by exchanging patches between peers • Improves working offline, enables private work • Common operations are fast (no communication with centralized server) • Does not rely on a single location for backups History: 3rd Generation • BitKeeper • DVCS, used for Linux kernel development 2002-2005 • Git - created by Linus Torvalds in 2005 for Linux kernel development • Supports distributed BitKeeper-like workflow • Focus on high performance, strong safeguards against corruption • Most widely used VCS according to 2014 Eclipse Foundation community survey and 2015 Stack Overflow developer survey • Mercurial • Like Git, created because of the withdrawal of the free version of BitKeeper • GNU arch, Bazaar, ArX No longer developed Version Control in Practice • Practical use of Git and GitHub • Live session… Best Practices "What you should • Commits always try to do" • Self-contained change sets (“one purpose”), with unit tests • Good commit message with helpful title (“Fix issue #42”, “Add tutorial”) • Pull requests • Clean build and test suite must pass (checked via CI) • Refer to issue in issue tracker • Follow pull request policy1 of corresponding project 1Example: https://github.com/scala/scala/blob/2.13.x/CONTRIBUTING.md References • Scott Chacon and Ben Straub. Pro Git https://git-scm.com/book CC BY-NC-SA 3.0 • GitHub Help - About pull requests https://help.github.com/articles/about-pull-requests/ • GitHub Guides https://guides.github.com/ Q: What is a group of software developers called? A: A merge conflict..