Escolar Documentos
Profissional Documentos
Cultura Documentos
Control Systems
- Emphasis on Distributed -
By Jari Aalto
© Jari Aalto 1
Terminology
(*) SCM is also used for Software configuration Management © Jari Aalto 2
Collaboration: Basic Problems
© Jari Aalto 3
Collaboration: Convential Solutions
• Never two persons work at the same time. When one person
finishes, he notifies other / sends work to others.
– Problems: Unsafe, Doesn’t scale, copies float around
• Shared directory (Windows network share; Unix/Linux NFS)
– Problems: Access restrictions, permissions etc. See above
• File is locked during edit (Windows; Unix/Linux *.lock files)
– Problems: Someone forgots to unlock, program left open
© Jari Aalto 4
Benefits of Version Control
• Single developer
– possibility to revert to a previous revision (backup)
– Code review between changes (revision differences)
• Team development
– Noticing changes immediately
– Separation of development lines (stable/devel branches)
– Improves project structure (directories, naming conventions)
– Easy sharing of code in new projects
© Jari Aalto 5
Version Control Systems Compared*
• Not the biggest FOSS project, but probably the most active
• 10 MiB code changes a months (in form of patches)
• ≈ 20 000 files, 280 MiB sources, approx. 5.5-7 million lines
of code.
• Many branches
– Short life: develop a feature, a fix. Merged when ready
– Long life: bigger features that need separate line of development
(ReiserFs4, Ext4 etc.)
– Test, debug: a modification goes through several phases before feature is
accepted to mainline (*-mm trees etc.)
© Jari Aalto 7
Version Control System Maturity
Features
Commercial
Git (C/sh)
= star
BitKeeper Bzr (P)
= dvcs Hg (P)
ClearCase
Open Source Accurev
Perforce Darcs (H)
= star Mtn (C)
MS TFS
= dvcs
Svn (C) (Arch C/sh)
Cvs (C) MS VSS Programming languages:
GNU Rcs (C) C, (H)askel, (P)ython, (sh)ell
[*] = The first FOSS DCVS; GNU Arch, unused by 2006 © Jari Aalto 10
DVCS Release Schedules
Open Source
usable!
Git
0.1 - 1.0 1.5 1.6 1.6.4
Git (2005-04-07)
4 12 1 2 4 6 2 6
Hg
0.1 - 0.7 0.9.3 0.9.4 0.9.5 1.0 1.3.1
Hg (2005-05-27)
5 6 9 1 4 7 12 6 10 3
Bzr Speed
0.1 - 0.6
12 0.9 1.0 (2.0)
Bzr (2005-03-22)
3 4 6 8 9 10 8 11 12 1 4 5 6 7 8 9 1112
Time
2005 2006 2007 2008 2009
© Jari Aalto 11
Pace of Development (1/3)
Git
Bzr
Hg
Source: Gmane.org
© Jari Aalto 12
Pace of Development (2/3)
Git
Bzr
Hg
Source: www.ohloh.net
© Jari Aalto 13
Pace of Development (3/3)
Git
Bzr
Hg
Source: www.ohloh.net
© Jari Aalto 14
DVCS and FOSS projects
Linux 2.6.30 sources (ca. 28 000 files, 1700 dirs; 350 MiB)
• Bzr
– Overall slowness, branching efficiently is difficult (special setup).
– Branches are "directories”. Good cross-platform line ending control.
– Cherry picks are just "merges" that are not tracked (cf. Git).
© Jari Aalto 20
State of DVCS: Git
© Jari Aalto 21
State of DVCS: Hg
© Jari Aalto 22
State of DVCS: Bzr
© Jari Aalto 23
Conclusions
– Git will dominate technically and offer ”enough rope to hang oneself
multiple times”. On the other hand support for git is easy to find. Extremely
flexible but a complex system.
– Bzr will probably be the choice of corporates: is has clear migration plan: 1)
same command set as those in centralized VCS and 2) it offers an easy
migration plan. User can choose centralized or distributed model. Big
shoulders: GNU and Canonical backing. Speed is no longer an issue.
– Hg has too little development power to keep in pace with the two.
(*) DVCS Round-up: One System to Rule Them All by Robert Fendt 2009-01-19
© Jari Aalto 24