Version Control

Soware Quality Quality Audit and Cerﬁcaon

Master in Computer Engineering

Introducon

• Change-control procedures. Avoid uncontrolled changes, destabilize and degrade quality: • In requirements, disrupt design and coding • In design, code disagrees with requirements • In the code, inconsistencies and uncertaines about what has been reviewed and tested – Version Control Systems (VCS): • Standalone (CVS, Subversion, Git,…) • Word processors (Microso Oﬃce, OpenOﬃce,…) • Content Management Systems (Drupal, Joomla,…) • Wikis (MediaWiki, TWiki, Trac (wiki+svn)…) Features

• Backup and Restore. Files are saved as they are edited, and you can jump to any moment in me • Synchronizaon. Lets people share ﬁles and stay up-to-date with the latest version • Short-term undo. Throw away your changes and go back to the “last known good” version in the database • Long-term undo. Jump back to the old version, and see what change was made that day • Track Changes. As ﬁles are updated, you can leave messages explaining why the change happened (stored in the VCS) • Track Ownership. A VCS tags every change with the name of the person who made it • Sandboxing. You can make temporary changes in an isolated area and test before “checking in” changes • Branching and merging. A larger sandbox. You can branch a copy of your code into a separate area and modify it in isolaon (tracking changes separately). Later, you can merge your work back into the common area Basic Setup

• Repository (repo): The database storing the ﬁles • Server: The computer storing the repo • Client: The computer connecng to the repo • Working Set/Working Copy: Your local directory of ﬁles, where you make changes • Trunk/Main: The primary locaon for code in the repo, the main development line Basic Acons

• Add: Put a file into the repo and begin tracking it • Revision: What version a file is on (v1, v2, v3,...) • Head: The latest revision in the repo • Check out: Download a file from the repo • Check in: Upload a file to the repository (if it has changed). The file gets a new revision number • Check in Message: A short message describing what was changed • Changelog/History: A list of changes made to a file since it was created • Update/Sync: Synchronize your files with the repository to grab the latest revisions of all files • Revert: Throw away your local changes and reload the latest version from the repository Advanced Acons

• Branch: Create a separate copy of a file/folder for private use (bug fixing, tesng, …) • Diff/Change/Delta: Finding the differences between two files. Useful for seeing what changed between revisions • Merge (or patch): Apply the changes from one file to another, to bring it up-to- date. For example, you can merge features from one branch into another • Conflict: When pending changes to a file contradict each other (both changes cannot be applied) • Resolve: Fixing the changes that contradict each other and checking in the correct version • Locking: Taking control of a file so nobody else can edit it unl you unlock it. Some version control systems use this to avoid conflicts • Breaking the lock: Forcibly unlocking a file so you can edit it. It may be needed if someone locks a file and goes on vacaon • Check out for edit: Checking out an “editable” version of a file. Some VCS have editable files by default, others require an explicit command Scenario

1. Alice adds a ﬁle (list.txt) to the repository 2. She checks it out, makes a change (puts “milk” on the list), and checks it back in with message (“Added required item.”)

svn add list.txt (modify the file) svn ci list.txt -m "Added required item"!

Examples based on the Subversion (svn) VCS 3. Bob updates his local working set and sees the latest revision of list.txt 4. He can browse the changelog or diﬀ to see that Alice put “milk” Checkin

• Each me we check in a new version, we get a new revision (r1, r2, r3, etc.) Checkout

• If mulple editors, ﬁrst checkout last version

svn co list.txt (get latest version) ...edit file... svn revert list.txt (throw away changes)

svn co -r2 list.txt (check out particular version) Diﬀs

• To know what has changed between versions – Most version control systems store diﬀs rather than full copies of the ﬁle

svn diff -r3:4 list.txt Branching

• Branches let us copy code into a new “folder” so we can modify it separately

svn copy trunk branch Merging

• Merge changes from one branch to another – Apply the changes from the new branch and add that to main

cd /trunk svn merge -r5:6 branch Conﬂicts

• Changes are automacally merged but somemes there are conﬂicts Conﬂicts

• When changes overlap and contradict, the VCS reports a conﬂict and avoids check in • Asks user to resolve it, approaches: – Check out latest version and re-apply changes • Example: sync to r4 and add “hot dog” to the list that already has “cheese” – Check out latest version, copy over your version and check in • Examples: this removes “cheese” and replaces it with “hot dog” Tagging

• Label any revision for easy reference

(in trunk) svn copy revision tag Distributed Version Control

• Centralised VCSs (like Subversion) helps backup, track and synchronise ﬁles • However, complicate for merging and branching changes people make – As projects grow, you want to split features into chunks, developing and tesng in isolaon and slowly merging changes into the main line • Distributed CVSs make branching and merging painless because they rely on it, so it easier to share changes – DVCS, done right, the best of both worlds: simple merging and centralized releases Distributed VCS (DVCS)

• Every developer has its own repository • Everyone can push changes into a common repo to share them DVCS Core Concepts

• Centralized version control focuses on synchronizing, tracking, and backing up ﬁles. • Distributed version control focuses on sharing changes; every change has a unique id • Downloading and applying a change are separate steps (in a centralized system, they happen together). • Distributed systems have no forced structure. You can create “centrally administered” locaons or keep everyone as peers.

• New Terminology – push: send a change to another repository (may require permission) – pull: grab a change from a repository Key Advantages

• Everyone has a local sandbox. Make changes and roll back on your local machine – No more giant checkins; your incremental history is in your repo • It works oﬄine. Just need to be online to share changes • It’s fast. Diﬀs, commits and reverts are all done locally • It handles changes well. Distributed VCS were built around sharing changes – Every change has a guid to track it • Branching and merging is easy. Every developer has “own branch” and guids facilitate to combine changes and avoid duplicates Key Disadvantages

• You sll need a backup. A machine to push changes to – In Subversion, central server stores main repo; do the same for a Distributed VCS • There’s not really a “latest version”. Each developer diﬀerent version, not necessarily one the latest – A central locaon helps clarify what the latest “stable” release is • There aren’t really revision numbers. Every repo has its own revision numbers, like guid ba63e7f – Tag revisions with meaningful names Basic Commands

• Addional Resources (in the “Addional Resources” folder): – git-cheat-sheet-large.png – gitcheatsheet.pdf – rc094-010d-git_2.pdf

Repository Structure

• Once inialised, the repository structure: – A working copy. The ﬁles currently being edited – A repository. A directory (.git in Git) containing all patches and metadata (comments, guids, branches, etc.)

Users have their own repos, with independent revision histories Understanding Updates and Merging

• Updates happen in several steps: – Geng the change into a repo (fetch) – Applying changes to ﬁles (pull or rebase, checkout) – Saving the new version (commit) Understanding Updates and Merging

• Depending on the change, you can update or merge: – Updates happen when there’s no ambiguity • Example: I pull changes to a file that only you’ve been eding. The file just jumps to the latest revision, since there’s no overlapping changes – Merges are needed when there are conflicng changes. • Example: If we both edit a file, we end up with two “branches”. In this case we (probably) want to merge the changes together Merging Scenario

• Conﬂicts are typically detected and solved quickly, the DVCS keeps track of: – The parent/child relaonship among changes (the merged list has two parents) – The “heads” or latest changes in each branch (before merge two heads, aer just one)

• A merge is needed because (+Soup) and (+Juice) are changes to a common parent: the list with just “Milk”. • Aer Joe merges the ﬁles, Sue can do a regular “pull and update” to get the combined ﬁle from Joe. She doesn’t have to merge again on her own. Organizing a Distributed Project

• Sue, Joe and Eve check changes into a common branch. Later, a maintainer can review and pull changes from the experimental branch into a stable branch, which has the latest release DVCS Usage Models

• A distributed VCS helps isolate changes but sll can provide the “single source” of a centralized system • Support many models of development: – From “pull only” (where maintainers decide what to take, and is used when developing Linux) – … – To “shared push” (which acts like a centralized system)

• Tech Talk: Linus Torvalds on git hp://www.youtube.com/watch?v=4XpnKHJAok8

Rebase Workflow hp://stackoverflow.com/quesons/457927/git-workflow-and-rebase-vs-merge-quesons

• In fact, our workflow is a little different, as we tend to do squash merges instead of raw merges. This allows us to turn our entire feature branch into a single commit on master. • Then we delete our feature branch. This allows us to logically structure our commits on master, even if they're a little messy on our branches. • So, this is what we do:

clone the remote repo git checkout -b my_new_feature ..work and commit some stuff git rebase master ..work and commit some stuff git rebase master ..finish the feature git checkout master git merge --squash my_new_feature git branch -D my_new_feature Acvity

• Share your miniproject at Github ( hp://github.com) and set and organisaon for your group (one account for each group member) • Some help (hp://help.github.com): – Download and install Git, Set up SSH keys and user info: hp://help.github.com/mac-set-up-git/ – Create a repository: hp://help.github.com/create-a-repo/ – Follow friends and projects, issues and organisaons: hp://help.github.com/be-social/