CSS 390: Notes from Lecture 3 (DRAFT)
Source Code Management
Many of you have used a source code management (SCM) system such as
git (particularly via
github.com).
If you haven't used such a system, you've at least, at some point,
copied your source files somewhere to make a backup.
Source code control, or management is the single most important
software engineering practice. Without it, you are DOA; nothing
else matters.
Why SCM?
-
legal: you may have to prove that you wrote software
-
change history shows that it didn't spring full-grown from
your forehead
-
reproducibility
-
rebuild current or previous production versions
-
diagnostic
-
find out when a bug was introduced, or who introduced it, by
comparing versions
-
backups
Most important:
-
ensure that everyone is working on the right version
-
don't clobber someone else's changes
Concepts
-
revision history: series of snapshots (checkins or commits)
-
tag: label attached to "important" commits, e.g. release versions
-
trunk: main branch
-
branch: sequence of changes forked off another branch
-
feature branch: branch made for sequence of changes to
implement a single feature or bug fix (may or may not be
deleted after merging into the
trunk)
-
diff: the lines different between two versions of a file
-
merge: copy changes from one branch to another or from branch into
workspace
-
automatic merging compares non-overlapping blocks of text
-
it's best to have an extra pair of eyes to make sure the merge
makes sense semantically
-
merge conflict: both versions have altered the same lines of text
-
must be resolved manually, typically using a merge tool
-
cherrypick: merge of selected ("cherry-picked") commits
-
triggers
-
enforce code review before commit
-
enforce unit tests before commit
-
continuous build/test/integration
Variations
Numerous
SCM systems, both commercial and open source.
Concepts are pretty basic, but details differ widely across system.
-
centralized vs. decentralized
-
locking vs. merging
-
command line vs GUI
-
which one can be scripted?
-
per-file versioning vs system-wide versioning (changelists)
-
changelist: atomic check-in of changes to several files,
typically representing a single feature or bug fix
Git
-
distibuted: no central repository
-
communication with upstream/downstream servers: push/pull
-
multi-protocol: http, ssh
-
command-line and graphical clients
-
relatively cheap branching and merging: branches are encouraged
for feature immplementation
-
easy to switch between branches:
git checkout
-
pull request: request to owner of upstream server to issue a pull request
(after review)
-
this is for downstream clients that do not have upstream write privlileges
-
typically request is granted after code review
-
2-step commit process: only commits staged changes
-
numerous tutorials online
Github
-
commercial service that hosts git repositories
-
free for open-source
-
private, paid accounts
-
good place to post your portfolio
-
you do have a portfolio, right?
Live Demo
https://github.com/systems-deployment/uwb-css490
-
look at the change history, not just the final result
-
after iteration, we can use topten as both a utility program
and a web server
-
use of built-in slice (array-list) and dictionary (map) types
-
counter implements the required sorting interface
-
use of library modules: regular expressions, buffered I/O
