COSC345 Software Engineering Version Control Outline • Some Problems – Communications – File system problems • Version control – Basic principles and use • When to use version control • Examples – SCCS – RCS – Subversion • Best practice Programmer Communications • Programmers need to know – Who is working on which files • To avoid collisions – Who made which changes to which files • Who broke my code! – How to get • The latest version of a source code file • How to rollback to the most recent working version • Any given version in which a bug is reported • Programmers need to manage – Different configurations (different OS / versions) – Concurrent debugging sessions The File System • The problem lies in the file system – Most file systems are absent of version numbers – Most file systems don’t keep logs of file modifications – Backup files • Get lost • Cumbersome to create • Are hard to manage • Reasons for creating backups become forgotten – Today its possible to keep all old versions • How will we manage just the ones worth keeping? – Just the versions of source code that compile? • The problem lies in the computer – Which old edits are worth keeping? Version Control • Storage and organization mechanism for backups – A database of old (and new) versions with notes • Allows users to – Retrieve old versions of a file – Track changes (who, what, and when) – Edit a file while another user is editing it – Use good housekeeping practices (documentation) • Version control systems store – Who made a change – What they changed – When they changed it – Why they changed it (supplied by the user) Basic Structure • Centralized archive – Held on file server • Decentralized development – Copies held in local directories – Different developers, different versions – Developers can sync with the archives Working file Archive Working file Working file Terminology • Archive – The version control system database • Working File – A file ready for use • Version – A file at some point in time • Revisions – Changes of, or corrections to, a version • Delta (diffs) – Representation of the differences between two versions – Allow the reconstruction of versions from each other Basic Operations • Check-out and Get – Get an (editable) version onto the file system – Allows user to say which version • Check-in – Replace a file in the archive – Allows user to describe the nature of the changes – Auto-increments a version number • Administration – View logs and view differences – Difference finding tool – Locking mechanisms – Access control (is this really necessary?) Basic File Access To do a build Version Control Operating System Get Make To do a set of edits Version Control Operating System Check-out Open Edit Save Make Check-in Branches • Multiple divergent development paths – Debug one release while working on another – Make substantial changes nondestructively • Trunk – A linear procession of versions • Branch – A path of versions away from a trunk • Version number – A trunk, branch, and version • E.g. 1.3.2.2 Keywords Embedding • Add substitution markers to files – Most useful of which is version number • Which can be used in “about” boxes Lock Management • Get – Get a read only copy of the file • Check-out – Get an read/write copy of the file – Prevent multiple check-outs of same version When to use Version Control • Always • When an audit trail is needed – Always – Who changes what, when and why • For group development – Always – Prevents file breakages – Manages multiple concurrent edits – Manages change merging (multi-way) When to use Version Control • When multiple configurations exist – Always – Different operating systems • Requires multiple concurrent changes • Manage file system transport to different O/S (cr/lf, etc) • For non-programming tasks – Always – Writing and publishing (including HTML) – Engineering (drawings) • Always Rewards • Prevents accidental breakages • Prevents accidental losses • Base-lining before experimentation • Centralized auto-builds (with cron) • Centralized backups • Becomes a developers “safety-net” Examples • SCCS – Source Code Control System – 1972, Marc Rochkind at AT&T Bell Labs – GNU version • Compatibly Stupid Source Control (CSSC) – Stores diff and rebuilds each file each time – Still seen on Tru64 – No multi-way merging • RCS - Revision Control System – 1982, Walter F. Tichy. RCS at Purdue University – 1991, RCS was licensed under GPL – Designed to be used by multiple developers – Stores latest version and reverse diffs Examples • Subversion – Open source replacement for CVS – Used in COSC345 • Tons of others – PVCS – SourceSafe – TeamSuite • Distributed version control – Git – Mercurial SCCS • admin – Create an SCCS archive for a given file > admin –n s.hello.c • get – obtain a version of the file for editing > get –e –l s.hello.c > vi hello.c • delta – Save the changes > delta s.hello.c comments? • unget > unget s.hello.c SCCS • prs > prs s.hello.c /whirlpool/stage5/andrew/sccs/s.hello.c: D 1.3 06/03/16 11:39:33 andrew 3 2 00001/00000/00006 MRs: COMMENTS: added include of stdlib /whirlpool/stage5/andrew/sccs/s.hello.c: D 1.2 06/03/16 11:38:48 andrew 2 1 00006/00000/00000 MRs: COMMENTS: First cut /whirlpool/stage5/andrew/sccs/s.hello.c: D 1.1 06/03/16 11:38:30 andrew 1 0 00000/00000/00000 MRs: COMMENTS: date and time created 06/03/16 11:38:30 by andrew SCCS Files • S file – The SCCS archive • G file – The working file • L file – List of deltas for a given file 1.3 06/03/16 11:39:33 andrew added include of stdlib 1.2 06/03/16 11:38:48 andrew First cut 1.1 06/03/16 11:38:30 andrew date and time created 06/03/16 11:38:30 by andrew • P file – Details of current version 1.3 1.4 andrew 06/03/16 11:42:59 • Z file – Lock file used to prevent concurrent archive file access RCS • Create an archive > mkdir RCS • Co – Check out (-l[<version>] if changes needed) > co –l2.5 hello.c • Ci – Check in > ci hello.c RCS • Rlog > rlog hello.c RCS file: RCS/hello.c,v Working file: hello.c head: 1.2 branch: locks: strict access list: symbolic names: comment leader: " * " keyword substitution: kv total revisions: 2; selected revisions: 2 description: Test. ---------------------------- revision 1.2 date: 2006/03/16 02:20:55; author: andrew; state: Exp; lines: +0 -1 removed SCCS verison header ---------------------------- revision 1.1 date: 2006/03/16 02:00:40; author: andrew; state: Exp; Initial revision ========================================================================== Subversion (TortoiseSVN) • Using the TortoiseSVN Interface: – Subversion archives are shown in the file manager TortoiseSVN – Check-in & out Checkout Checkin TortoiseSVN – Overlay Icons Fresh checked-out working copy (normal) Locally changed file (modified) There are conflicts between the local and the archive versions of this file – it requires manual effort to resolve (conflict) You must get a lock before you can modify this file (readonly) You have a lock and the status is normal File scheduled for deletion from version control File scheduled for addition to version control TortoiseSVN – History TortoiseSVN – Differences • Different versions are shown side-by-side with the differences highlighted Distributed Version Control • Typified by: Git, Mercurial, and Bazaar • Designed for large or distributed development groups • Each developer – Takes a snapshot (pulls) from the central archive • Protected against loss (because its also a backup) – Check in and out of their local archive – Occasionally synchronise with each other • Managers (committers) – Push to the central repository • Advantages: – Allows developers to work off-line – Faster because syncs are usually local – Allows private experiments without branching the central repository • Disadvantages – Merging is difficult and time consuming – Initial setup (cloning the archive) takes time Best Practice • Always use version control • Integrate it with your IDE • Do not share the sandbox • Do not work outside the sandbox • Do not bring contaminants into the sandbox • Keep the sandbox in sync with the repository – Keep system clock in sync too • Check-in often – Keep the sandbox clean • Build early and often Best Practice • Label each release • Branch after each release • Branch before every bug fixing period • Assign ownership to trunks and branches .