copyright © 2015 – curt hill version control systems why use? what systems? what functions?
TRANSCRIPT
Copyright © 2015 – Curt Hill
Version Control Systems
Why use?What systems?What functions?
What are they?• Software that stores different
versions of documents– Documents are usually source code – May also include auxiliary items:
• Test cases• Documentation • Make files
• Allow developers to recreate the way the system was at a previous time– Somewhat like an editor undo but much
larger and more complicatedCopyright © 2015 – Curt Hill
Problems That are Solved• Program is updated but the fix broke
something else– Cannot find all the places changed to
restore to original state– Problem not detected until much later
• Two people make changes to a program– Both changes work alone– When put together it does not work
Copyright © 2015 – Curt Hill
Versions• Often refers to a succession of the
same program– Windows 7 and 8 are different versions
• May also refer to different targets– Linux for Intel vs. Linux for ARM– Lots in common but differences in
various places
Copyright © 2015 – Curt Hill
What do they do?• Keep multiple versions of any
relevant documents• Maintain information about changes
– Who made the change– Comments on what the change did– Dates of the versions
• Allows code to be checked out, changed and then checked back in
• Show differences between two files
Copyright © 2015 – Curt Hill
What not to keep?• Anything that can be generated:• Object or machine language
– Generated by compilers
• Documentation that is machine generated by:– JavaDoc– Doxygen– Any other document generator
• Anything else that can never change
Copyright © 2015 – Curt Hill
The Process• A repository keeps the documents
– Very specialized database
• Developer checks out a document• This is edited to improve it• It is checked back in (aka committed)
with the control information• If the repository supports:
– Automatic unit tests are run– Failure of these can retract the check in
Copyright © 2015 – Curt Hill
Terminology• Version – updated copy of a document• Branch – new target of a document
– Versions are automatically created, but branches are not
– Allows multiple current documents
• Merge – making two branches into one• Project – a set of files pertaining to
one program or system• Conflict – a check in of two items that
do not agreeCopyright © 2015 – Curt Hill
First Branch Support• The C preprocessor was the first
attempt to handle multiple platforms• This uses the #if, #ifdef, #ifndef etc.• Code specific to a single hardware or
compiler could be incorporated without separating into two separate files– The separate files will defy proper
maintenance
Copyright © 2015 – Curt Hill
Example Branch• Version 1.0 is released• Version 1.1 is an improvement• Before 1.1 is ready for release a
problem is found and a bug fix generated– Create 1.0.1
• We now have a branch of 1.1 and 1.0.1
Copyright © 2015 – Curt Hill
A Branch
Copyright © 2015 – Curt Hill
1.0 1.1
1.0.1
Example Merge• Two branches
– 1.1 is still under development– 1.0.1 is stable
• Version 1.1 has some improvements which we do not want to discard
• What is needed is to merge the fix of 1.0.1 into 1.1
Copyright © 2015 – Curt Hill
A Merge
Copyright © 2015 – Curt Hill
1.0 1.1
1.0.1
1.2
Example Again• It is possible that the changes of 1.1
did not need the bug fix of 1.0.1 because it tried another approach to the same code– If so the 1.0.1 becomes a dead end and
is not developed further
• The version numbers are likely to be maintained by the version control and more version numbers will be generated
Copyright © 2015 – Curt Hill
Branching Again• The branch before produced a dead
end after the changes were merged with the developed new version
• Branches are often more permanent– One branch for Windows– One branch for Mac– Both will be continued indefinitely
Copyright © 2015 – Curt Hill
Simultaneous Checkout
Copyright © 2015 – Curt Hill
1.2
1.2a
1.2b
Suppose two or more developers check out the same code in a day.What will happen on check in?
Several Options• Some systems only allow the first
check in– This will force the second one to
reconcile the two sets of changes
• Some systems will accept both provided they do not touch any of the same lines
• Some will merge both and then run tests and reject them if they do not work
Copyright © 2015 – Curt Hill
Check in
Copyright © 2015 – Curt Hill
1.2
1.3
1.3
Top checked in first and retained. Bottom checks out 1.3 and then applies different changes.
1.4
Distributed• Many of the older version control
systems relied on a single repository– Easy to maintain, but only one disk error
from disaster
• Distributed version controls are more robust but much more complicated
Copyright © 2015 – Curt Hill
Distributed Again• A distributed version control system
has multiple repositories • How are they kept synchronized?• A push is a repository telling others
about changes in a project• A pull is a repository asking for
updates from another• Push/pull usually involves multiple
files instead of single files
Copyright © 2015 – Curt Hill
Systems• SCCS• RCS• PVCS• Subversion• GIT• Mercurial• Many others
Copyright © 2015 – Curt Hill
SCCS• Source Code Control System• UNIX• May be first, no later that early
1970s• Stored originals and then the
differences between a version and the next version
Copyright © 2015 – Curt Hill
RCS• Revision Control System • Update of SCCS, also on UNIX• Keep current and uses differences to
go back in time
Copyright © 2015 – Curt Hill
CVS• Concurrent Version System• Update of RCS but operates on
several types of systems• Uses client / server approach
Copyright © 2015 – Curt Hill
Subversion• An update of CVS• May apply versioning to directories
and metadata– Not just files
• Atomic check-in– No overwriting
• Client Server model– Clients may be on different machines
Copyright © 2015 – Curt Hill
SVN Architecture
Copyright © 2015 – Curt Hill
GIT• An open-source, distributed version
control system– GITHUB seems to be the current choice
for open source projects
• Developed by Linus Torvalds for the LINUX kernel
• Designed for speed and scalability• Each developer gets a local copy of
the repository
Copyright © 2015 – Curt Hill
Mercurial• Another open-source, distributed
version control system with many similarities to GIT
Copyright © 2015 – Curt Hill
Conclusions• Version control is a requirement for
software development• Allows easy recreation of the project
at a particular time– Which makes it easier to find when a bug
was introduced
• Also supports branches– Different platforms or different
functionality while still maintaining the common code base
• The check out and check in feature enables teams
Copyright © 2015 – Curt Hill
Post Conclusions• Lets see if we can examine some of
these– Subversion– Git
Copyright © 2015 – Curt Hill