Version Control,
Revision Control
Software Configuration
Management
Version Control
During software development it is inevitable
•
To be able to recreate any earlier internally or externally released version of the
software product
•
Giving the possibility to turn back in case of development dead-end
•
Control changes of software source code continuously
•
Identify faults and problematic code parts more easily
SCM
•
•
•
•
Version Control is part of Software
Configuration Management (SCM),
which activity keeps coherent
software versions together.
Internal release: coherent software
build for verification (testing)
External release: coherent software
build for external, customer use
SCM usually refers more than VC, also
means product component
registration, 3PP related activities,
may be supply activities as well. It
depends on the actual project
(company) setup.
Traditional vs. Distributed
Traditional
•
•
server oriented
clients works online or make snapshots locally
Distributed
•
•
•
•
Peer to peer approach
All local machines have the whole (complete) repository
Local repos sync amongst each other
Only working copies exist (every cloned repo is a working copy)
•
No canonical, reference copy of the codebase exists by default; only working copies. = No
special authority for any repository
Common operations (such as commits, viewing history, and reverting changes) are fast, because
there is no need to communicate with a central server.
Communication is only necessary when sharing changes among other peers.
Each working copy effectively functions as a remote backup of the codebase and of its changehistory, protecting against data loss.
Disadvantages
•
•
•
•
•
•
initial cloning can be terribly long
missing reserved checkout is a problem in case non-mergable binary files
Traditional vs. Modern
• Traditional
• items (files) are version controlled and
every file can be checked in separately
• it does not guarantee that system is
continuously coherent
• Consider changes together
• all modified files are checked in as
one step and one identifier (generally
a hash) identifies the whole system
actual state
• cherry-picking is possible but not a
proposed way
• Traditional
• prevent parallel development by file
locking (reserved checkout)
• or by parallel development tracks and
integrate at the end
• Modern ones
• reserved checkout is not usual
• frequent merges are common and
forced by the tool
Version Control Implementations
•
•
•
•
•
•
(IBM Rational) Clearcase
Git
CVS, Subversion
Mercurial
Fossil
Internal
• Wiki pages
• Google Docs
• Microsoft Office
Clearcase Naming Conventions and
Branching
• This is a visual representation of
versions of one item, “above” this,
there is a file and folder view as in any
normal file structure
•
•
•
•
The root is “main” branch
Versions are numbered and
Branches are named
Labels indicating releases (see next
slide)
• Red arrows are merges
• “Config spec” tells what
you see from the system
Clearcase Complex Branching
Branching in general (DVCS)
• This is a visual representation of
versions of items or the whole repo (in
case of distributed systems), “under”
this, there is a file and folder view as in
any normal file structure
• The root is usually called “trunk”
• Red arrows are merges
Fossil and branching
• Hashes vs. incremental numbers
• Fig. 1: an ideal world
• Directed acyclic graphs (DAGs) but
everyday usage tree is enough
• “directed acyclic graph (DAG), is a
directed graph with no directed
cycles.” Link
• Forks (fossil tries to prevent forks)
• Warns to do fossil update to fetch the
other already committed version
• Git supports forks quite much
• Fig. 2-3
• Branches
• Deliberate forking for example
because of two teams using different
version of the SW
• Fig. 4
• Merge back to “main” – dashed
arrows
Fossil and branching
• A tag is a name that is attached to a
check-in.
• A property is a name/value pair.
• The branch tag tells (by its value) what
branch the check-in is a member of.
• The default branch is called "trunk.“
• Link to read in details.
Fossil and branching
• Branch
•
A branch is a set of check-ins with the same
value for their "branch" property.
• Leaf
•
A leaf is a check-in with no children in the
same branch.
• Closed Leaf
•
A closed leaf is any leaf with the closed tag.
These leaves are intended to never be
extended with descendants and hence are
omitted from lists of leaves in the commandline and web interface.
• Open Leaf
•
A open leaf is a leaf that is not closed.
• Fork
•
A fork is when a check-in has two or more
direct (non-merge) children in the same
branch.
• Branch Point (branching out)
•
A branch point occurs when a check-in has
two or more direct (non-merge) children in
different branches. A branch point is similar
to a fork, except that the children are in
different branches.
Concepts
Concepts
• Atomic operations
• File locking
• Version merging
• Baselines, labels and tags
Concepts and Branching Strategies
Concepts
• Store everything under version control
which you want to keep
• Not only source code files, but
•
•
•
•
configuration files
install scripts
documentation
released packages
• Nothing to delete, add a new version
• if an item is not needed remove from
version control but it means you have
all earlier version in repository
Branching strategies in a SW
Development Project
• one track
• one main, one development
• feature branches
• private branches
• fossil branching
Terms need to know and understand
• repository
• check out
• reserved
• unreserved
• check in
• merge
CEA 2/EEA 15 Planned RELEASE
BRANCHING
Faulty product’s
R-State on this
specific branch
<
New product
number created
for EEA 15
Corrected
product’s
R-State
> <CXP 902 …/3
P1B : R1B
P1A : R1A CXP 902 …/3
...
2.0 ICP1
Preship
2.0 PRA
Final build
R1A
2.0 ICP1
R1B
2.0 EP1
R1A/1
R1A : R1B
2.0 ICP2
R1C
CXP 902 …/2 R1B : R1A CXP 902 …/3
><
> <
...
15.0
Preship
#1 / #2
15.0 PRA
Final build
R2A
15.0
ICP1
R2B
15.0
ICP2
R2C
15.1 PRA
Final build
R3A
15.1
ICP1
R3B
15.1
ICP2
R3C
Fossil commands
• new/init
• clone
• open
• add
• rm
• checkout (quite different than usual,
do not use at first)
• changes
• revert
• diff
• gdiff
• commit/checkin
•
•
•
•
•
•
•
•
•
pull/push/sync
update (your local tree)
merge
undo
server
ui
close
extras
Autosync
• http://www.fossilscm.org/fossil/doc/trunk/www/quickst
art.wiki
• http://fossil-scm.org/xfer/help