Version Control. So#ware Quality Quality Audit and Cer2ﬁca2on. Master in Computer Engineering. Roberto García

Size: px

Start display at page:

Download "Version Control. So#ware Quality Quality Audit and Cer2ﬁca2on. Master in Computer Engineering. Roberto García"

Linette Brooks
5 years ago
Views:

1 Version Control So#ware Quality Quality Audit and Cer2ﬁca2on Master in Computer Engineering Roberto García

2 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 Oﬃce, OpenOﬃce, ) Content Management Systems (Drupal, Joomla, ) Wikis (MediaWiki, TWiki, Trac (wiki+svn) )

3 Features Backup and Restore. Files are saved as they are edited, and you can jump to any moment in 2me SynchronizaAon. 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 isola2on (tracking changes separately). Later, you can merge your work back into the common area

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

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

6 Advanced Ac2ons Branch: Create a separate copy of a ﬁle/folder for private use (bug ﬁxing, tes2ng, ) Diﬀ/Change/Delta: Finding the diﬀerences between two ﬁles. Useful for seeing what changed between revisions Merge (or patch): Apply the changes from one ﬁle to another, to bring it up- to- date. For example, you can merge features from one branch into another Conﬂict: When pending changes to a ﬁle 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 ﬁle so nobody else can edit it un2l you unlock it. Some version control systems use this to avoid conﬂicts Breaking the lock: Forcibly unlocking a ﬁle so you can edit it. It may be needed if someone locks a ﬁle and goes on vaca2on Check out for edit: Checking out an editable version of a ﬁle. Some VCS have editable ﬁles by default, others require an explicit command

7 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

8 Checkin Each 2me we check in a new version, we get a new revision (r1, r2, r3, etc.)

9 Checkout If mul2ple 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)

10 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

11 Branching Branches let us copy code into a new folder so we can modify it separately svn copy trunk branch

12 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

13 Conﬂicts Changes are automa2cally merged but someames there are conﬂicts

14 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

15 Tagging Label any revision for easy reference (in trunk) svn copy revision tag

16 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 tes2ng in isola2on 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

17 Distributed VCS (DVCS) Every developer has its own repository Everyone can push changes into a common repo to share them

18 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 loca2ons or keep everyone as peers. New Terminology push: send a change to another repository (may require permission) pull: grab a change from a repository

19 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

20 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 diﬀerent version, not necessarily one the latest A central loca2on 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

21 Basic Commands Addi2onal Resources (in the Addi2onal Resources folder): git- cheat- sheet- large.png gitcheatsheet.pdf rc d- git_2.pdf

23 Repository Structure Once ini2alised, 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

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

25 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 ﬁle that only you ve been edi2ng. The ﬁle just jumps to the latest revision, since there s no overlapping changes Merges are needed when there are conﬂic2ng changes. Example: If we both edit a ﬁle, 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 rela2onship among changes (the merged list has two parents) The heads or latest changes

26 Merging Scenario Conﬂicts are typically detected and solved quickly, the DVCS keeps track of: The parent/child rela2onship among changes (the merged list has two parents) The heads or latest changes in each branch (before merge two heads, aler just one) A merge is needed because (+Soup) and (+Juice) are changes to a common parent: the list with just Milk. A#er 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.

27 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

28 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 hpp://

31 Rebase Workﬂow hpp://stackoverﬂow.com/ques2ons/457927/git- workﬂow- 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. 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

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

2/9/2013 LAB OUTLINE INTRODUCTION TO VCS WHY VERSION CONTROL SYSTEM(VCS)? II SENG 371 SOFTWARE EVOLUTION VERSION CONTROL SYSTEMS

2/9/2013 LAB OUTLINE INTRODUCTION TO VCS WHY VERSION CONTROL SYSTEM(VCS)? II SENG 371 SOFTWARE EVOLUTION VERSION CONTROL SYSTEMS SENG 371 SOFTWARE EVOLUTION LAB OUTLINE Introduction to Version Control Systems VERSION CONTROL SYSTEMS Subversion Git and Github 1 Prepared by Pratik Jain 2 INTRODUCTION TO VCS A version control system