Revision Control

Last modified Tuesday, 09-Dec-2025 17:22:31 UTC.

Configuration Management
- Products of the software development process include product code, documents, test vectors, test harnesses.
- Throughout the lifecycle, these will change; configuration management monitors and controls these changes.
- Elements of configuration management include:
  - Build control - determining which versions of code are required to build a product (make, ant, gradle, maven, etc.)
  - Revision control - keeping track of various versions of code and documentation (Git, CVS, SVN, etc.)
  - Change control - the procedure by which code and documentation changes are reviewed, decided upon, incorporated and recorded.
  - Release managment - tracking product releases and their features.
- Reasons for wanting to formalize revision control include:
  - Learn from history - we may need to revisit previous versions of code and documentation to review changes and validate them
  - Support multiple product versions - not all users want to upgrade so we still need to support old versions of the code in addition to the most recent version
  - Support concurrent development - without suitable controls, multiple programmers working on the same source tree can overwrite each others' work.
Versions and Version Numbering Schemes
- After release of a system there are two sources of changes:
  - Continuing development causes new internal versions to be created.
  - Defects are detected as the product is used in the field and fixes for these defects are applied to the release version of the product.
- Concurrent development continues until it is time to create a new release of the product.
  - The new release incorporates both new features and functionality that have been generated by ongoing development and any defect fixes that have been made as part of product maintenance.
  - Some time before the next release, product development and product maintenance (defect fixes) are suspended while the development and maintenance lines are merged into a single pre-release version of the product.
  - After successfully creating the pre-release merged version a new release is created.
- Version numbers are used to identify the various versions of a product throughout its lifecycle.
  - A version numbering scheme determines how version numbers are generated and assigned.
  - Example:
    - Uses a major and a minor version number.
    - An even major number is assigned to production versions that are released for general use.
    - An odd major version number is assigned to internal development versions.
    - The minor number indicates an incremental change from a previous version.
- File and module version numbers
  - A product might consist of many individual modules each of which progresses through several versions
  - The various versions of the modules are given their own numbers.
  - Need some way of tracking of the module versions and which versions of each of the modules are used to make a version of the product.
Tracking changes in files
- Creating a new file every time a modification is made is possible, but
  - Keeping track of the files would be unwieldy for even a small number of files.
  - It would waste space; a one-byte change to every file in the tree would double the size of the tree.
  - A more efficient way is to store the initial version and record changes
  - Or store the most recent version and record undo information.
- To regenerate a previous version of a file, start with the current version then apply reverse changes until the desired version is created.
- Example:
  - Start with the file HelloWorld.c-0
  - Modify the file to produce an extended greeting HelloWorld.c-1
  - Calculate the differences between the two files using
```
prompt> diff -e HelloWorld.c-1 HelloWorld.c-0 > delta.1 
```
    and you get delta.1
```
13a
    printf("Have a most excellent day\n");
.
12c
    printf("Hello world\n");
.
10d
```
  - delta.1 contains a list of commands which, when executed by the ed editor will change HelloWorld.c-1 back into HelloWorld.c-0
  - To make ed work as a stream editor, add a line 1,$p to the end of delta.1, so ed prints out the file after editing.
  - Delete HelloWorld.c-0 and generate on demand with
```
prompt> ed - HelloWorld.c-1 < delta.1
```
Git and Github
- Git is a free and open source distributed version control system designed to handle everything from small to very large projects. Git runs a repository on your computer.
- Github hosting service for software development and version control using Git. Github runs in the cloud, and stores files from your local Git repository.
- You can run Git alone, or hook it up to a Github repository.
- If you don't have Git on your computer, you should get it.
- If you don't have a Github account, you should make one and create a personal access token. Copy your token and save it somewhere safe.
- You can learn to be a Git pro! Jack likes this presentation.
Basic git
- Identify yourself to Git. Use the same user name as for Github.
```
git config --global user.name "YOUR_USERNAME"
git config --global user.email "YOUR_EMAIL"
```
- Make a repository for your project
  - Keep all your project files in one directory hierarchy
  - Initialize the repository
```
git init 
```
  - Check that the repository is initialized.
```
git status 
```
    Note how you are told which branch you are working on in "On branch branch_name" (more about branching below). Git maintains a HEAD pointer to the commit of the branch you are on. The main banch is called master or main, depending on your version of Git.
- Add files
  - Add files to the staging area
```
git add HelloWorld.c 
```
  - Optionally, check that the files are staged
```
git status 
```
  - Commit the files
```
git commit -m "SOME USEFUL MESSAGE" 
```
  - Look at the log
```
git log 
```
  - Commit whenever you want after making changes. To avoid having to do a "git add" each time, use
```
git commit -a -m "SOME USEFUL MESSAGE" 
```
  - After changes and further commits, look at the log
```
git log 
```
- Tagging releases
  - Tag specific points in a repository's history as being important. Often used to mark releases
  - Add a tag
```
git tag -a "v1.4" -m "This is release 1.4" 
```
  - List existing tags
```
git tag 
```
  - Show tag data
```
git show "v1.4" 
```
- Go back to a previous state
  - By reset to delete changes back to a commit.
```
git reset --hard commit_hash_from_log 
```
    Beware, this throws away everything after that commit.
  - By revert to save the changes inbetween
```
git revert commit_hashes_from_log 
```
    where commit_hashes_from_log is a list of the commits you want to undo, in reverse chronological order.
Using Github
- Tell your local Git to use your access token. You will have to provide it when you first "push" (see below)
```
git config --global credential.helper store
```
  Git stores it as plain text in ~/.git-credentials, which is insane. Better options are available.
- Create a repository in Github - accept defaults for now.
- Get the repository HTTPS URL from the "Code" button.
- Link the local repository with Github
```
git remote add origin the_github_url 
```
- Push the local repository to Github. This first time you have to provide your Github login, and your access token as the password.
```
git push -u origin master 
```
  master could also be main, depending on your version of Git.
- At stable points after some commits push again (note you just "push")
```
git push 
```
- You can view the commmited code in Github.
- You can share your private repository with friends (or the TA). You can make a repository public, if you want the whole world to see your work (i.e., not for coursework).
- You can clone copy a repository from Github to a local computer.
```
git clone the_github_url 
```
Git branches
- Branching means you diverge from the main line of development and continue to do work without messing with that main line.
- Find out your current branch name with
```
git branch 
```
- Create a branch with
```
git branch branch_name 
```
- Switch to the branch
```
git checkout branch_name 
```
- Push the branch to Github
```
git push --set-upstream origin branch_name 
```
- Switch branches and edit as required, commit and push changes
- See the all branches as a tree
```
git log --all --graph 
```
  If you have the repository in Github, see it there at under the Insights tab (or repository_url/network).
- If you forget which branch you are on, ask Git
```
git status 
```
  or
```
git log 
```
- Merge another branch's changes into the current branch
```
git merge other_branch_name 
```
- If the two branches are compatible, the changes are merged. If the two branches are not compatible you'll get a message, and you have to edit the affected files, then commit.
- Delete branches you are done with
```
git branch -d branch_name 
```
Cooperating with Github.
- Synchronization in the presence of concurrency
  - A pessimistic protocol forces a programmer to obtain an explicit lock on the file before it is modified and to release the lock when the modifications are complete; only one programmer can ever be modifying a file at any time.
  - An optimistic protocol assumes that the likelihood of two programmers modifying the same file at the same time is low, so the protocol allows multiple programmers to make copies of a file and modify the copies as they please. The protocol detects any conflicts generated by attempts to place modified files back into the tree and forces resolution of all conflicts before replacement is allowed.
- A simple optimistic protocol using Github:
  - Team leader creates a repository, adds collaborators with write access
  - Each collaborator clones and edits and commits
  - Each collaborator pulls any changes that have been pushed by others
  - If other changes clash with local changes git reports a "merge conflict"
  - Look for delimiter lines "<<<<<<<" and "=======" (your changes) and ">>>>>>>" (the changes you are trying to pull).
  - Decide what to keep/delete/change, and remove the delimiter lines
  - Commit and push
- A safer optimistic protocol using Github:
  - Team leader creates a repository, adds collaborators with read access
  - Each collaborator clones, creates a new branch, edits, commits, and pushes to their branch.
  - Collaborator creates a pull request (PR) in Github to request merging the local branch into the main branch. Discussion takes place in the PR.
  - Team leader approves and merges the PR
Release managment in Github.
- You can create new releases with release notes, as well as edit or delete existing releases.
- Read the excellent online instructions.

Exercises

Exam Style Questions

Describe and differentiate between pessimistic and optimistic protocols for file symchronization.