6. Case study “lonley developer”
“L onley D ev already released version 1.0 of his “great A pp”, that now is in production.
H e's working on the code of the next version (2.0) since a couple of weeks.
L onley D ev is very happy, since he removed a lot of duplications from his code and – even if
currently “Great A pp” doesn't work at all due to the refactoring of some parts – he plans
to release the next greatest and stable version (2.0) within a couple of weeks.
Suddenly the phone rings... “
7. Case study “lonley developer”
“H ello?“
“H i there, H ere's C ustomer.
W e hav found a critical bug on 1.0! “
WTF !
... sorry?
Nope ...
D What's Well, ...
e that? C
blah,
blah, u
blah,... s
e 5 minutes later
OMG . ... blah, blah, blah,
o ... r e a l l y serious ... o
.. m
p blah, blah ...
... I see... I can fix it for the e
e next rel.
U will have it within 2 weeks, R U kidding? We need it
ok? N O W!
Of
FUCK! .
course Have a
.. nice day!
8.
9. Case study “lonley developer”
Solutions
E x p e r ie n c e d N o o b ie
LD LD
He ha s a c opy
o f 1. 0 Loos e
fa c e Loos e
“Wait for w ork
2.0”
... but twice effort
to fix also in 2.0
10.
11. How?
VCS allow teams to collaborate
( yes L D dude, even you with your brain...)
VCS manage change and allow for inspection
by tracking ownership
by tracking evolution of changes
by allowing for branching
by allowing for continuous integration
12. VCS Taxonomy
VCS
Centraliz Distribute
Local
ed d
SCCS CVS Git
RCS SVN Mercurial
14. VCS Taxonomy
VCS
Centraliz Distribute
Local
ed d
SCCS CVS Git
RCS SVN Mercurial
15. Centralized VCS
Client / Server R e p o s it o
ry
t co
mi mm
commit
m it
co
checkout
t ch
ou ec
ck ko
he ut
c
Ann Ben
D e v e lo p e D e v e lo p e Yo u r
r 's r 's lo c a l
lo c a l lo c a l c opy
c opy c opy
16. Centralized VCS
Single server with revision information
Clients c h e c k o u t a working copy locally
Most operations happen on the server
Linear revision history
17. Centralized VCS
R e p o s it o r y : R e p o s it o
ry
Keeps versions histories.
Holds official version of resources
Differences between versions as delta
18. checkout & commit
TIME
R e p o s it o r y
index.html (ver
Wo r k s p a c e
ut
1.2)
ko
page1.html (ver
ec
*index.html (ver 1.2(ver
index.html -
1.32)
ch
modified)
1.2)
page1.html (ver 1.32) style.css (ver 1.4)
page1.html (ver
*style.css (ver 1.4 –
1.32)
modified)
style.css
*page2.html(new)(ver 1.4)
R e p o s it o r y
co
index.html (ver
mm
1.3)
it
page1.html (ver
1.32)
style.css (ver 1.5)
page2.html (ver
1.1)
19. checkout & commit
checkout: with this command, one can summon files or sets of files
from the repository based on date, tag, branch, or any of a number of other
criteria.
commit: with this command, one can summon files or sets of files from
the repository based on date, tag, branch, or any of a number of other
criteria.
update: will automatically bring your workspace up-to-date with the latest
(or however you specify) files from the
repository, automatically merging non-exclusive
changes between files and initiating conflict resolution if necessary. Updates
involving conflicts solicit information from the user how they wish to have a
conflict resolve.
20. update
TIME
Wo r k s p a c e
index.html (ver 1.2)
page1.html (ver 1.32)
*style.css (ver 1.14 –
modified)
*page2.html(ver 1.1 – modified) R e p o s it o r y
*page3.html(new)
index.html (ver
1.4)
page1.html (ver
1.32)
Wo r k s p a c e
te
style.css (ver 1.15)
da
page2.html (ver
index.html (ver 1.4 – up 1.2)
updated) image.png (ver 1.3)
page1.html (ver 1.32)
*style.css (ver 1.14 –
conflict)
*page2.html(ver 1.2 – updated
& still
Changed in the meanwhile
modified) by other developers...
*page3.html(new)
image.png (ver 1.1– updated)
22. VCS Taxonomy
VCS
Centraliz Distribute
Local
ed d
SCCS CVS Git
RCS SVN Mercurial
23. Distributed VCS co
m
m
i
tB e n
D e v e lo p e
Peer-to-Peer r 's
node
ll
pu
pu
sh
pu
sh
ll
co
pu
co
/
m
/
m
/
/
sh
pu
m
pu
m
ll
pu
ll
sh
pu
i i
tA n n push / pull t
D e v e lo p e Yo u r
r's pull / push node
node
24. Distributed VCS
Every client has a copy of the full repository locally
All repository operations are local (except sharing)
Intelligent network operations when sharing content
A very non linear revision history
Large online communities to share changes
25. Distributed VCS
B r a n c h p a r ty!
M e r g e = weaving together two (or more)
local branches into one.
Creating and destroying branches are simple
operations so it's easy to experimen with
new ideas.
Very easy to isolate changes.
Unlike CVCS, you don't have to specify
anything about where you're merging from
and to; the trees automatically know what
their split point was in the past.
26. DVCS vs CVCS
C o lla b o r a t io n
Developers can easily collaborate directly without
needing a central authority or dealing with server
administration costs
27. DVCS vs CVCS
O f f -lin e o p e r a t io n s
Developers can still be productive and not
worry about a central server going down...
(remember the days of complaining that
CVS was down and you couldn't work?)
29. IDE Facilities
F ile a n n o t a t io n s
Allows you to see who changed what when, line by line.
Useful for tracking bugs and responsability.
Can be used in combination with diff and history for even more info.
31. Conclusion
- The future of version control.
VCS - Lesson learned at Eclipse & Linux
- Version controller enables nice
code review workflow.
Centraliz Distribute
Local
ed d
SCCS CVS Git
RCS SVN Mercurial