Version Control So#ware Quality Quality Audit and Cer2ficaon Master in Computer Engineering Roberto García ([email protected]) Introduc2on • 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 uncertain2es about what has been reviewed and tested – Version Control Systems (VCS): • Standalone (CVS, Subversion, Git,…) • Word processors (MicrosoL Office, OpenOffice,…) • 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 2me • Synchronizaon. Lets people share files 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 files 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 files • Server: The computer storing the repo • Client: The computer connec2ng to the repo • Working Set/Working Copy: Your local directory of files, where you make changes • Trunk/Main: The primary locaon for code in the repo, the main development line Basic Ac2ons • 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 Ac2ons • Branch: Create a separate copy of a file/folder for private use (bug fixing, tes2ng, …) • 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 un2l 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 file (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 diff to see that Alice put “milk” Checkin • Each 2me we check in a new version, we get a new revision (r1, r2, r3, etc.) Checkout • If mul2ple editors, first 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) Diffs • To know what has changed between versions – Most version control systems store diffs rather than full copies of the file 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 Conflicts • Changes are automacally merged but someAmes there are conflicts Conflicts • When changes overlap and contradict, the VCS reports a conflict 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 files • However, complicate for merging and branching changes people make – As projects grow, you want to split features into chunks, developing and tes2ng 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 files. • 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 offline. Just need to be online to share changes • It’s fast. Diffs, 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 sAll 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 different 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 • Addi2onal Resources (in the “Addi2onal Resources” folder): – git-cheat-sheet-large.png – gitcheatsheet.pdf – rc094-010d-git_2.pdf Repository Structure • Once ini2alised, the repository structure: – A working copy. The files 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 files (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 edi2ng. The file just jumps to the latest revision, since there’s no overlapping changes – Merges are needed when there are conflic2ng 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 • Conflicts 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 files, Sue can do a regular “pull and update” to get the combined file 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 s2ll 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 hpp://stackoverflow.com/ques2ons/457927/git-workflow-and-rebase-vs-merge-ques2ons • 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.