SCMnbsp; SCM? Software Configuration Management

1 . SCM David Stotts UNC Computer Science (2013) with slides from a talk by Karsten Dambekalns (2005) 

2 .SCM?  Software Configuration Management  Software Change Management  Source Code Management  Revision control system  Version control system 

3 .What’s the problem?  More work you do, the more you can lose  The more iterations you make, the harder it is to remember what was in each one, harder to retrace  More people involved, more likely they are to conflict with each other  Undo and Redo need to be macro-scale … “Big Smart Backup” 

4 .SCM Benefits  Collaboration SCM tools prevent one user from accidentally overwriting the changes of another, allowing many developers to work on the same code without stepping one each other's toes.  History SCM tools track the complete development history of the software, including the exact changes which have occurred between releases and who made those changes. 

5 .SCM Benefits  Release notes generation Given the tracking of each change, the SCM can be used to generate notes for their software releases which accurately capture all of the changes included in the new release.  Documentation and test management SCM tools can be used to manage not just software source code, but also test suites and documentation for their software.  Change notifications To keep interested members of the team informed when changes occur to the source code. 

6 .SCM Users  Project Developers writing source code, individual or team work  Open Source Communities project developers, to the nth degree  Advanced Users / Education wishing to examine source code  Testers needing to download the latest release/version  Archives / History FreeBSD CVS tree goes back to mid ’80s and more 

7 .SCM Objects  Project  Source code  Tests (code)  Document / file / binary  Build scripts  Reporting / Notification scripts  Version tree  Log / History 

8 .SCM Systems at SourceForge  CVS Oldie but goodie, 1986, originally in Unix, central server, manages projects on top of RCS (files only)  SubVersion (SVN) 2000, Apache Software Foundation, better CVS  Git 2005, Linus Torvalds (Linux), distributed model, fast updates/merges  Mercurial Matt Mackall, 2005, distributed cross platform, written in Python mostly  Bazaar 2005, Canonical (UK), written in Python by Martin Pool, distributed and/or central model, GNU project 

9 .Common Work Cycle Work, work, work retrace Try it Sweet Rats !! !! Good? Bad? 

10 .Manual Retrace/Versioning  Keep backup folders (v1, v2-stable, etc.)  Tarballs (v1.tar.gz, v2.tar.gz, etc.)  Comment out large chunks of code  Write down notes (ReadMe, help.txt, code comment blocks? )  Maybe save it on a file share if you are thinking backup safety 

11 .SCM Vocabulary Repository This is the (central) copy of the source code with all the history and archive information Working copy What Jane and Joe use to actually work on, each has their own one Checkout The process of fetching the repository content you need to your machine Commit Write changes (save) to the repository Update Get latest files (with committed changes) from the repository 

12 .SCM Work Capture Work, work, work Rats!! fix Try it Sweet!! commit repository 

13 .SCM Work Cycle Work, work, work last commit previous version Try it Bad? Sweet Rats !! !! Good? Really bad? revert commit repository 

14 .SCM Work Cycle So typical SCM work cycle looks like this:  Update your working copy gets others committed changes  Make your own changes  Examine your changes  Commit your changes resolve edit conflicts on fail (occasionally)  -- and again … 

15 .Collaboration Issues 

16 .Collaboration, Better Not Great Thing 

17 .Collaboration, SCM-style 

18 .Change Tracking Issues 

19 .Change Tracking via SCM 

20 .OK … eye rester … 

21 .Example: CVS  Concurrent Versions System  1986, Dick Grune  Extension of the Unix RCS  Widely used, was Unix standard  Handles collections of files as projects RCS was individual files only 

22 .CVS: Centralized Model  Client / server architecture  Central server is THE code repository  Developers run CVS clients, transfer files across network to local store for work  Commit copies files back to central repository  Detect conflicts for resolution 

23 .Centralized Server 

24 .Centralized Version Files 

25 .CVS: terminology  CVS labels a single project (set of related files) that it manages as a module  Server stores modules in its repository  Check out gives a user a copy of a module: the files are the working copy, sandbox, or workspace  Changes in the working copy are reflected in the repository by committing them  To update is to acquire or merge the changes in the repository with the working copy. 

26 .CVS: update working copy 

27 .CVS: make changes 

28 .CVS: examine your changes 

29 .CVS: examine change history