1. Source Code Management Revision Control Version Control Systems (VCS) Tal Maoz

2. 26/03/092 outline What is “source code management” ? History Vocabulary CVS Subversion (SVN) GIT

3. 26/03/093 What is source code management? roughly, tools for tracking multiple versions of files over time –developers track evolution of source code –system administrators track configuration files basic capabilities –check stuff in –check stuff out (current version, or any historical one) –tag sets of files as a particular release –resolve conflicting changes using some merging tools examples –RCS, CVS, Subversion, git, Perforce, bitkeeper, visual sourcesafe, …

4. 26/03/094 Why have source code management (SCM)? document state of a system and rationale for changes coordinate simultaneous deployment of multiple changes to complex systems allow reversion to previous versions in case of problems ease sharing code on multi-developer projects facilitate code audits business continuity - speed system re-creation compliance (CAP, Sarbanes-Oxley, PCI-DSS, …)

5. 26/03/095 Tools Traditionally developers use stand-alone tools Over time VCS have been embedded into other software: –Integrated Development Environments (IDEs) Eclipse, Netbeans, Visual Studio –word processors Microsoft Word, OpenOffice.org Writer, KOffice, Pages, Google Docs –Spreadsheets OpenOffice.org Calc, Google Spreadsheets, Microsoft Excel –Various content management systems –Key feature of wiki software packages MediaWiki, DokuWiki, TWiki allows to revert a page to a previous revision, track each other's edits, correct mistakes, defend public wikis against vandalism and spam.

6. 26/03/096 Types of VCS Centralized –cvs, svn, … –One repository in a central location –Users checkout projects, modify and commit changes Distributed –Git –Many central repositories –Checkout a local copy of the repository –Work locally, merge with central repositories –Lieutenants are project members who have the power to dynamically decide which branches to merge. –Good: no need for network, faster, private work, can work with no permissions, no single point of faliure –Bad: difficult to understand, harder to keep secure, no dedicated version (multiple versions)

7. 26/03/097 History 1950s: CM (Configuration Management) - hardware development and production control applied to software development –The first software configuration management was most likely done manually. Early 1960s or even late 1950s: CDC UPDATE and IBM IEB_UPDATE Late 1960s, early 1970s: Professor Leon Pressor (University of California, Santa Barbara) –thesis on change and configuration control, a contract with a defense contractor who made aircraft engines for the US Navy Early 1970s: Unix make By 1970 CDC UPDATE was an advanced product Circa 1972: Bell Labs paper describing the original diff algorithm 1972, with an IEEE paper in 1975: source code control system, SCCS, Marc Rochkind Bell Labs –Originally programmed in SNOBOL for OS/360; subsequently rewritten in C for Unix (used diff for comparing files) 197x: Pansophic's PANVALET –an early source code control system for the mainframe market

8. 26/03/098 History (2) 1975: Professor Pressor's work grows into a commercial product – “Change and Configuration Control (CCC)” –sold by the SoftTool corporation Revision Control System (RCS, Walter Tichy) Early 1980s: patch (around 1988, Larry Wall) 1984: Aide-de-Camp 1986: Concurrent Version System (CVS) 2000: Subversion initiated by CollabNet Early 2000s: distributed revision control systems like BitKeeper and GNU arch become viable 2005: GIT is developed by Linus Torvalds for the Linux Kernel source

9. 26/03/099 History (3) Until the 1980s, SCM could only be understood as CM applied to software development. –identification and baseline (well-defined point in the evolution of a project) –Still needed a set of techniques oriented towards the control of the activity, and using formal processes, documents, request forms, control boards etc. Afterwards, the use of software tools applying directly to software pieces representing the actual resources –allowes SCM to grow as an autonomous entity (from traditional CM). The use of different tools has actually led to very distinct emphases –Traditional CM for Software, typically around Change Mananagement (examples: Continuus, CVS or ClearCase UCM) –Line oriented management, based on patches or Change Sets –Focused on Derived Objects and Build Management (example: Base ClearCase/clearmake)

10. 26/03/0910 Vocabulary Trunk - The unique line of development that is not a branch (sometimes also called Baseline or Mainline) Baseline - An approved revision of a document or source file from which subsequent changes can be made. Mainline - Similar to Trunk, but there can be a Mainline for each branch. Branch - A set of files under version control may be branched or forked at a point in time so that, from that time forward, two copies of those files may be developed at different speeds or in different ways independently of the other. Repository - The repository is where files' current and historical data are stored, often on a server. Sometimes also called a depot (e.g. with SVK, AccuRev and Perforce). Working copy - The working copy is the local copy of files from a repository, at a specific time or revision. All work done to the files in a repository is initially done on a working copy, hence the name. Conceptually, it is a sandbox. Checkout - A check-out (or checkout or co) creates a local working copy from the repository. Either a specific revision is specified, or the latest is obtained.

11. 26/03/0911 Vocabulary (2) Commit - A commit (checkin, ci or, more rarely, install, submit or record) occurs when a copy of the changes made to the working copy is written or merged into the repository. Update - An update (or sync) merges changes that have been made in the repository (e.g. by other people) into the local working copy. Merge - An operation in which two sets of changes are applied to a file or set of files. –one user updates their working copy with changes made and checked into the repository by other users. –A set of files has been branched, a pre-existing problem is fixed in one branch and the fix is merged to the other branch –may happen after files have been branched, developed independently for a while and then are required to be merged back into a single unified trunk Conflict - Occurs when two changes are made by different parties to the same document, and the system is unable to reconcile the changes. A user must resolve the conflict by combining the changes, or by favoring one set of changes. Resolve - The act of user intervention to address a conflict between different changes to the same document. Export - An export is similar to a check-out except that it creates a clean directory tree without the version control metadata used in a working copy. Often used prior to publishing the contents.

12. 26/03/0912 Vocabulary (3) Label / Tag - Refers to an important snapshot in time, consistent across many files. These may all be tagged with a user-friendly, meaningful name or revision number. Head - The most recent commit. Import - An import is the action of copying a local directory tree (that is not currently a working copy) into the repository for the first time. Reverse integration - The process of merging different team branches into the main trunk of the versioning system. Revision / Version - Any change in form. In SVK, a Revision is the state at a point in time of the entire tree in the repository. Change - A change (or diff, or delta) represents a specific modification to a document under version control. The granularity of the modification considered a change varies between version control systems. Change list - On many version control systems with atomic multi-change commits, a changelist, change set, or patch identifies the set of changes made in a single commit. This can also represent a sequential view of the source code, allowing source to be examined as of any particular changelist ID.

13. 26/03/0913 CVS (Concurrent Versions System) Centralized Built for text files Repository can be local or on a server Several developers may work on the same project concurrently –edit files within one’s own "working copy“ –sending (or checking in) modifications to the server –the server only accepts changes made to the most recent version of a file –developers are expected to keep their working copy up-to-date by incorporating other people's changes on a regular basis Each file has it’s own version number –Updated automatically with each commit Clients can compare versions, request a complete history of changes, or check out a historical snapshot of the project as of a given date or as of a revision number.

14. 26/03/0914

15. 26/03/0915

16. 26/03/0916

17. 26/03/0917

18. 26/03/0918

19. 26/03/0919

20. 26/03/0920

21. 26/03/0921

22. 26/03/0922 CVS – Local Repository Set environment variable CVSROOT to a desired location Initialize the repository with ‘cvs init’ Import a project by going into it’s directory and using: –cvs imoprt –m “description” {project name} {version} {vendor} Checkout –cvs co {project name} –cvs checkout {project name} Add/Delete files –cvs add/remove {file/dir} –to remove, first delete the file/dir Update working copy –cvs update [-Pd] Commit –cvs commit –m “description” [file/dir]

23. 26/03/0923 CVS – Remote Repository Create repository as before Configure CVS server (standalone / inetd) Add allowed users to repository configs Login: –cvs -d:pserver:{user}@{server}:{repository} login Checkout –cvs -d:pserver:{user}@{server}:{repository} co {project} … Logout –cvs -d:pserver:{user}@{server}:{repository} logout

24. 26/03/0924 SVN - Subversion Commits are true atomic operations. Renamed/copied/moved/removed files retain full revision history. Directories, renames, and file metadata (but not timestamps) are versioned. Entire directory trees can be moved around and/or copied very quickly, and retain full revision history. Native support for binary files, with space-efficient binary-diff storage. Apache HTTP Server as network server, WebDAV/DeltaV for protocol. There is also an independent server process that uses a custom protocol over TCP/IP. Branching and tagging are cheap operations, independent of file size, though Subversion itself does not distinguish between a tag, a branch, and a directory

25. 26/03/0925 SVN (2) Natively client/server, layered library design. Client/server protocol sends diffs in both directions. Costs are proportional to change size, not data size. File locking for unmergeable files ("reserved checkouts"). Path-based authorization. PHP, Python, Perl, and Java language bindings. Full MIME support - the MIME Type of each file can be viewed or changed, with the software knowing which MIME types can have their differences from previous versions shown.

26. 26/03/0926 SVN – Common Commands browse in a repository –svn ls {repository} [-R] import a project –svn import {project} {repository} [–m “project checkin message”] check out a project –svn co [-r {rev}] {repository} {path} add a file –svn add {file/dir} commit changes –svn ci [file/dir] [-m “message”] Revert –Svn revert [file/dir]

27. 26/03/0927 SVN – Advanced Commands Diff –svn –r{rev A}:{rev B} [file/dir] Create a branch –svn copy {path to trunk} {path to branch} Merging –svn merge –r{rev A}:{rev B} {path to branch}

28. 26/03/0928 GIT background Developed by Linus Torvald Purpose: to facilitate Linux kernel development Consider CVS/SVN as the evil

29. 26/03/0929 GIT Distributed Strong support for non-linear development. –rapid branching and merging –tools for visualizing and navigating a non-linear development history –Assumption: a change will be merged more often than it is written Distributed development –gives each developer a local copy of the entire development history –changes are copied from one such repository to another –changes are imported as additional development branches Repositories can be published via HTTP, FTP, rsync, or a Git protocol over either a plain socket or ssh Efficient handling of large projects –an order of magnitude faster than other revision control systems –two orders of magnitude faster on some operations Cryptographic authentication of history –the name of a revision (a "commit") depends upon the complete development history leading up to that commit (SHA-1) –not possible to change the old versions without it being noticed

30. 26/03/0930 GIT (2) Everyone can hold a repository Can merge your repository with any other repository –Can even merge with several repositories! Can track changes made locally or remotely Keep history reports from several repositories when merging Reliability –File corruption, RAM corruption, Macilious users –GIT tracks the content of the whole repo, not single file, not only filenames –GIT use SHA1 for data integrity: file, commit, repo... –Consequently: May not check in a single file May not check out a single file Break a big project to sub projects smartly :)

31. 26/03/0931

32. 26/03/0932 Everyday tasks with GIT GIT has many routines: –“git merge” –“git pull” –“git push” –“gitk” –“git init” –“git config” GIT man page –“man git-merge”

33. 26/03/0933 Everyday tasks with GIT Introduce yourself to GIT –“git config –global user.name “Trung”” –“git config –global user.email “u0407784@nus.edu.sg””u0407784@nus.edu.sg Create a repo –“git init” Clone a repo –“git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6” –git clone ssh://trunglt@aye.comp.nus.edu.sg/home/min/forecite/

34. 26/03/0934 Everyday tasks with GIT Lean a bit about GIT concepts: –Repo: your local repo and remote repos –Reference in history: either commit or merge –Branch: “master” is the default branch name. Do not give name such as test1, test2... but test_login, rel_iteration1 –SHA1 –Tag: a friendly name for a commit (version 1.0 vs e74g64a21...) –Head: you see that branch is a series of commits. A branch name also means the latest commit on that branch

35. 26/03/0935 Everyday tasks with GIT HEAD: the commit that you are working on HEAD^, HEAD^^, HEAD~3 = HEAD^^^, HEAD^1, HEAD^2

36. 26/03/0936 Everyday tasks with GIT Create a branch: –“git branch ” Delete a branch: –“git branch -d ” List branch: –“git branch” –“git branch -r” //remote branch Jump to a commit: –“git checkout ” –“git checkout -b ”

37. 26/03/0937 Everyday tasks with GIT Give remote repo a nicer name: –“git remote add min ssh:// @aye.comp.nus.edu.sg/home/min/parcite” Fetch changes from Min: –“get fetch min” Merge with the master branch of Min's repo: –“get merge min/master” Or in one shot: git pull min

38. 26/03/0938 Everyday tasks with GIT View SHA1 of a commit: –Git rev-list HEAD^..HEAD View logs: –“git log” –“git log HEAD~4..HEAD” –“git log –pretty=oneline v1.0..v2.0 | wc-l –git log --raw -r --abbrev=40 –pretty=oneline origin..HEAD –git archive --format=tar --prefix=project/ HEAD | gzip >latest.tar.gz –“git blame ”

39. 26/03/0939 Everyday tasks with GIT Git commit and merge: –Git has its own index database –When you edit your repo, there are 3 things: HEAD: the reference in history from that you are editing Cached: whatever you have just added and run git add The remaining files that you have not ask git to keep track

40. 26/03/0940 Everyday tasks with GIT Create new repo –mkdir ~/myProject –cd ~/myProject –git init Simple ops –git add {file/dir} –git rm {file/dir} –git mv {file/dir} Make a commit: –git commit [-a] –m “description” Clone –mkdir /tmp/myClone –cd /tmp/myClone –git clone ~/myProject

41. 26/03/0941 Everyday tasks with GIT Git merge: –“git pull min” OR (“git fetch min” then “git merge min”) –Conflicts $ git show :1:file.txt # the file in a common ancestor of both branches $ git show :2:file.txt # the version from HEAD, but including any # nonconflicting changes from MERGE_HEAD $ git show :3:file.txt # the version from MERGE_HEAD, but including any # nonconflicting changes from HEAD. –Resolve the conflicts / reset and ask others to help

42. 26/03/0942 Everyday tasks with GIT Reset the conflicted merge: use git-reset “git reset –mixed –Reset the index database to the moment before merging “git reset –hard –Reset the index database and the working data “git reset –soft –You made a commit and also made some typo mistake. This commands help us fix those errors without touching the working data and index database

43. 26/03/0943 Everyday tasks with GIT “git reset” help you to revert the most recent commit only Revert older commit by hiding is bad Use “git revert” to introduce a patch to revert the merge/commit done. This is left as an exercise

44. 26/03/0944 Everyday tasks with GIT Last thing: how to ignore files in a repo: –Use.gitignore: list files that you want to ignore –Put.gitignore in the directory containing the files –Example: Ruby on Rails project –Example: C/C++ project

45. 26/03/0945 Everyday tasks with GIT Quality Assurance? How Linux developer keep track of bugs: “git bisect”: binary search for a bug in a series of commits: –git bisect start –git bisect good v2.6.17 –git bisect bad v2.6.18