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 …
16.Collaboration, Better Not Great Thing
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
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