ì
Computer Systems and Networks
ECPE 170 – Jeff Shafer – University of the Pacific
Version Control
2
Lab Schedule
ì Today
ì Lab 2 – Version Control
ì Next Week
ì Intro to C (for C++ programmers)
ì Lab 3 – Build Tools
ì Deadlines
ì Lab 1 Report – Jan 28th, 2017 by 5am
ì Submit via Canvas
ì Lab 2 Report – Jan 30th, 2017 by 5am
ì Submit via version control
Computer Systems and Networks Spring 2017
3
Before Version Control
1. <[Link]> 7. <[Link]>
2. <[Link]> 8. <Report-2a-WITH-
[Link]>
3. <[Link]>
9. Email off to partner…
4. Email off to partner… Partner responds with new doc
<[Link]>
5. <[Link]>
10. <[Link]>
6. Partner responds with doc
(that is missing the changes you 11. <Report-3-FINAL-OOPS-FIXED-
just made) [Link]>
Computer Systems and Networks Spring 2016
4
Version Control Features
ì Project history tracking
ì Concurrent file editing (merges)
ì Non-linear program history (branches)
ì Naming scheme for program releases (tags)
Computer Systems and Networks Spring 2016
5
Motivation for Version Control
ì Why would a single programmer (working alone)
use version control?
ì Backup files
ì Roll-back to earlier (working) version
ì See changes made between current (broken) code
and earlier (working) code
ì Maintain multiple versions of a single product
ì Experiment with a new feature
ì Try a risky change in a “sandbox”
ì If it works, you can merge it into the regular code.
If it fails, you can throw it away.
Computer Systems and Networks Spring 2016
6
Motivation for Version Control
ì Why would a small group of developers use
version control?
ì All the reasons a single programmer would, plus…
ì Merging different changes made by different
developers into the same file
ì Add a new function at the bottom? Safe to
automatically merge in
ì Re-write a function at the same time another
developer is also editing it? Version control will catch
this and ask you to decide which edits should “win”
ì Blame – who wrote this buggy code?!?
Computer Systems and Networks Spring 2016
7
Motivation for Version Control
ì Why would a large group of developers use
version control?
ì Different question: Could you develop the Linux
kernel, Adobe Photoshop, Google Chrome, etc…
using:
ì A single shared “folder of code”?
ì Emailing code snippets between developers?
ì Everyone sits around and shares one keyboard?
Computer Systems and Networks Spring 2016
8
Version Control Basics
ì What kind of files should I keep in version control?
ì Program source code (obviously)
ì VHDL / Verilog files (from digital design class)
ì Matlab scripts
ì HTML files
ì Server configuration files
ì Imagine you work at Livermore National Labs, and
your job is to manage Linux cluster computers with
100,000+ machines (nodes)…
ì Anything that is plain text!
Computer Systems and Networks Spring 2016
9
Version Control Basics
ì What kind of files should I not keep in
version control?
ì These aren’t “rules”, so much as “guidelines”…
ì Binary data
ì How do you merge two different binary files
together? No general-purpose way to do this
ì Anything auto-generated by the compiler
ì Object files or executable file
ì Wastes space on useless junk that can be re-
created automatically
ì Text editor temp files (e.g. main.c~)
Computer Systems and Networks Spring 2016
10
Version Control Basics
ì Big risk in putting the executable in version control
ì If you forget to compile before a commit, the
executable may not be in sync with the attached
source code!
ì Big headache if you ever roll back to this version!
ì In ECPE 170, all our executable files can be
produced in under 5 seconds with one command.
There’s no need to include them in your repository
Computer Systems and Networks Spring 2016
11
Distributed Version Control
ì Why do they call Mercurial a distributed version
control system?
ì Conventional systems (e.g., Subversion or “svn”)
have a centralized server hold the “master” copy
ì Distributed version control – each copy is its own
full-fledged master! (But you can still push changes
from one person’s copy to another)
ì Allows version control to work offline
ì Allows version control to work with ad-hoc groups
Computer Systems and Networks Spring 2016
12
Version Control in ECPE 170
ì Version control required for this class
ì Used to distribute boilerplate code for labs
ì Used to turn in assignments when finished
Computer Systems and Networks Spring 2016
13
Version Control in ECPE 170
ì If you only do one check-in at the very end
of your project, you've missed the whole
point of version control, and turned a
valuable tool into an obstacle to
completing the assignment
ì Check-in code on a
regular basis!
Computer Systems and Networks Spring 2016
14
Computer Systems and Networks Spring 2016
15
"If that doesn't fix it, [Link]
contains the phone number
of a friend of mine who
understands git. Just wait
through a few minutes of 'It's
really pretty simple, just
think of branches as...' and
eventually you'll learn the
commands that will fix
everything.”
[Link]
Computer Systems and Networks Spring 2016