COSC Software Engineering. Lecture 7: Version Control

Transcription

1 COSC Software Engineering Lecture 7: Version Control

2 Some Problems Communications File system problems Version control Basic principles and use Outline When to use version control Examples SCCS RCS Subversion Best practice

3 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 roll back 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

4 The File System The problem lies in the file system Most file systems lack 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 it s 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?

5 Versioned file systems IBM MVS (version = generation + cycle) Burroughs MCP (ditto) MIT s ITS VMS device:[directory]name.extension;version Original Apple file system had version numbers in API but not in user interface AT&T s 3-dimensional file system Apollo s DSEE DEC s Vesta Time Machine almost qualifies ZFS can take snapshots of file systems

6 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)

7 Centralized archive Held on file server Basic Structure Decentralized development Copies held in local directories Different developers, different versions Developers can sync with the archives Archive Working file Working file Working file

8 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

9 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?)

10 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

11 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

12 Keyword Embedding Add substitution markers to files Most useful of which are version number and date Which can be used in about boxes Get Get a read only copy of the file Check-out Lock Management Get a read/write copy of the file Prevent multiple check-outs of same version

13 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)

14 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

15 Rewards Prevents accidental breakages Prevents accidental losses Base-lining before experimentation Centralized auto-builds (with cron) Centralized backups Becomes a developers safety-net

16 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, Solaris, HP-UX, POSIX 2008 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

17 Examples Subversion Open source replacement for CVS Used in COSC345 Tons of others PVCS SourceSafe TeamSuite Git Mercurial

18 SCCS admin Create an SCCS archive for a given file get > admin n s.hello.c 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

19 SCCS prs > prs s.hello.c /whirlpool/stage5/andrew/sccs/s.hello.c: D /03/16 11:39:33 andrew /00000/00006 MRs: COMMENTS: added include of stdlib /whirlpool/stage5/andrew/sccs/s.hello.c: D /03/16 11:38:48 andrew /00000/00000 MRs: COMMENTS: First cut /whirlpool/stage5/andrew/sccs/s.hello.c: D /03/16 11:38:30 andrew /00000/00000 MRs: COMMENTS: date and time created 06/03/16 11:38:30 by andrew

20 SCCS Files S file The SCCS archive G file The working file L file List of deltas for a given file /03/16 11:39:33 andrew added include of stdlib /03/16 11:38:48 andrew First cut /03/16 11:38:30 andrew date and time created 06/03/16 11:38:30 by andrew P file Details of current version andrew 06/03/16 11:42:59 Z file Lock file used to prevent concurrent archive file access

21 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

22 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 ==========================================================================

23 Subversion (TortoiseSVN) Using the TortoiseSVN Interface: Subversion archives are shown in the file manager

24 TortoiseSVN Check-in & out Checkout Checkin

25 T h e i T h e i T h e i T h e i T h e i T h e i T h e i 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

26 TortoiseSVN History

27 TortoiseSVN Differences Different versions are shown side-by-side with the differences highlighted

28 Distributed Version Control Typified by: Git, Mercurial, and Bazaar Designed for very large development groups Each developer Takes a snapshot of the current archive Protected against loss (because it s also a backup) Check in and out of this local archive Occasionally synchronise with remote repositories Advantages: Allows developers to work off-line Faster because syncs are local Allows private experiments Disadvantages Merging Initial setup (cloning the archive) No locking

29 Best Practice Always use version control Integrate it with your IDE Xcode File Source Control 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

30 Label each release Best Practice Branch after each release Branch before every bug fixing period Assign ownership to trunks and branches Include version in About box, program output, log files, etc.