2. DVCS
Distributed version control (systems)
10-Feb-14
www.ambientia.net
2

3. What is DVCS?
Distributed revision control system
or
Distributed version control system
or
Decentralized version control system
or, simply
the greatest thing since sliced bread?
10-Feb-14
www.ambientia.net
3

4. What is Version Control?
• Belongs to Software Configuration Management
• Management of changes (over time) to
• Documents
• Source code
• Web sites (and any other collections of information)
1.0
2.0
2.1
3.0
file a
file b
file c
10-Feb-14
www.ambientia.net
4

5. Traditional VCS
Clien
t
• Centralized
Clien
t
• Client-server approach
• Single point of failure
Clien
t
Server
Clien
t
Clien
t
• Most operations require
network connection
• Support for locking
resources
Clien
t
Clien
t
10-Feb-14
www.ambientia.net
5

6. DVCS
Clien
t
Clien
t
Clien
t
• Peer-to-peer, based on
the exchange of patches
• Collaboration without
common network
• Every working copy is a
standalone repository
Clien
t
Clien
t
Clien
t
Clien
t
Clien
t
Clien
t
Clien
t
Clien
t
Clien
t
CI
QA
Rel.
Clien
t
10-Feb-14
www.ambientia.net
6

7. Basic Concepts
Jim
commit
changes
A
pull
A2
Clone
repository
push
10-Feb-14
Jill
www.ambientia.net
repository
clone
7

8. Terms
Repository
A container of assets, e.g. source code. Commonly a directory in a filesystem
containing
special meta-data about the repository contents (.git and .hg directories).
Working directory
The repository contents editable in the filesystem.
Commit, changeset
A change applied to the repository contents (multiple files at one) within a
transaction.
Given a unique identified (a hash code).
Patch
A set of commits (one or more) transferred between repositories.
Clone
A full copy of another (upstream) repository. The initial copying operation
of a repository
into another is called cloning.
Push
Making changesets from the local repository (source) available in another
(destination).
Pull
Making changesets from an external repository available locally.
10-Feb-14
www.ambientia.net
8

9. Benefits of DVCS
10-Feb-14
www.ambientia.net
9

10. Independence
Work can progress even when disconnected from the network
Bekathwia
Marysol*
10-Feb-14
www.ambientia.net
10

11. Speed
Most commonly used operations are extremely fast
Martin Heigan
10-Feb-14
www.ambientia.net
11

12. Safety
Every working copy is a full backup of the project repository
Myrrien
10-Feb-14
markjhandel
www.ambientia.net
12

13. Flexibility
Working model is up to the project team
Paul L Dineen
madprime
10-Feb-14
www.ambientia.net
13

14. Isolation
Work on new, great ideas now, share the results later
appel
ttcopley
10-Feb-14
www.ambientia.net
14

15. Disadvantages
• Cloning retrieves everything
• Uses a lot of bandwidth on the first clone
• Might use a lot of disk space as well
• Problematic for non-mergeable content
• No support for locking
• Locking can be useful for non-mergeable content
• Non-mergeable content?
• For example, graphics assets, i.e. large binary files
• Always stored in full, for every change
10-Feb-14
www.ambientia.net
15

16. Everything is a Branch
• Working copies
• Named branches
• Release branches
• Deployment targets
• Light-weight branches
• Feature branches
• Bug fix branches
• Exploratory branches
• Multiple heads in a repository
10-Feb-14
www.ambientia.net
FeatheredTar
(Mercurial)
16

17. Branching Model
• Everybody should know:
• When to branch; where to
branch from
• When to merge; where to
merge back to
• Tailor the model for your
environment
• Heavy vs. light
• Common model
• Git Flow
10-Feb-14
http://nvie.com/posts/a-successful-git-branching-model/
www.ambientia.net
17

18. Feature Branching
10-Feb-14
www.ambientia.net
18

19. Feature Branching Timeline
fork
merge changes
Pull
request
feat-X
develop
merge and remove branch
10-Feb-14
www.ambientia.net
19

20. Steps for Feature Branching
1. Fork a new branch for each individual change
2. Work on and test the branch in isolation
3. Pull changes from the mother branch
continuously (keep up-to-date with others)
4. When ready, publish the changes by creating a
pull request
• Let others review the pull request for quality control
5. Merge the accepted pull request back to the
upstream branch (mother branch)
6. Get rid of the (short-lived) feature branch
10-Feb-14
www.ambientia.net
20

21. Pull requests
• Clear point for reviews and quality control
• Checklists, formal reviews, performance testing
• Final merge can be done by an integrator (role)
• Multiple features/fixes developed in parallel
• Efficiency
• Isolation until final merge
• Mainline can maintain high level of quality at all times
• No need to delay work due to release preparation
• Release from mainline at will
10-Feb-14
www.ambientia.net
21

22. Atlassian Feature Branching
Atlassian DVCS and development flow

23. Atlassian DVCS support
• JIRA
JIRA
Bamboo
• Feature branch creation for issues
• Stash
• Git repository management
Stash
• Pull requests
• SourceTree
• Free (!) repository browser
SourceTree
• Bamboo
• Continuous integration
IDE / Editor
• Continuous releasing and/or
deployment
10-Feb-14
www.ambientia.net
23

24. Branching from JIRA
14.11.2013
www.ambientia.net
24

25. Checkout from Stash
14.11.2013
www.ambientia.net
25

26. SourceTree on developer’s computer
10-Feb-14
www.ambientia.net
26

27. Bamboo branch autodetection, ci
10-Feb-14
www.ambientia.net
27

28. Pull request from SourceTree
10-Feb-14
www.ambientia.net
28

29. Code reviews by pull requests
14.11.2013
www.ambientia.net
29

30. Merging the pull request
14.11.2013
www.ambientia.net
30

31. Images from Flickr
Images Creative Commons-licensed for commercial use
http://creativecommons.org/licenses/by-sa/2.0/legalcode
(The image owners’ Flickr URL attached to each image as a
hyperlink)
Screenshots from Atlassian
10-Feb-14 www.ambientia.net
31

32. Tomi Kallio
tomi.kallio@ambientia.fi
+358 40 749 2051
@tomi_kallio
10-Feb-14 www.ambientia.net
32