Title: Contemporary source control for Pharo Speaker: Max Leske Wed, August 20, 2:30pm – 3:00pm Video Part1: https://www.youtube.com/watch?v=fa9Zpxyt_no Video Part2: https://www.youtube.com/watch?v=vpag70LmGrY Description Abstract: SVN [1], Mercurial [2] and Git [3] probably are the predominant source control systems used for open source software. Each of these systems brings many tools to the table to visualize meta data, search for versions and content and, most importantly, manage versions and changes to versionable entities. Unfortunately for us, Pharo does not natively support any of these systems which makes access for newcomers harder and inhibits our sharing abilities. In this talk I want to: - show what support for different source control systems can do for us - present the work that is being done on integrating Git into Pharo - discuss how this work will enable the integration of arbitrary source control systems into Pharo - touch upon the future of Monticello and Metacello in Pharo [1] http://subversion.apache.org [2] http://mercurial.selenic.com [3] http://git-scm.com Bio: Max Leske is a master student of University of Bern and working with netstyle.ch

1. Contemporary source
control for Pharo
This is the talk about Git.
ESUG, 2014-08-10 Max Leske

2. Overview
background
current state
the future
(Git)
(Git)
(Git)

3. A bit of history

4. Revision control systems
Mercurial (2005) Git (2005)
CVS (1990)
Monotone (2003)
RCS (1982)
SVN (2000)
BitKeeper (1999)
SCCS (1972)
Random selection
distributed
centralized

5. Source control in Squeak
and Pharo
Monticello 2
Monticello
DVS
CVS
RCS
Greatly
exaggerated

6. “The stupid content tracker from hell”
A bit about Git

7. Git objects
reference
commit
tree
tree tree
blob blob blob

8. Git repositories
Synchronization point
(usually)
repository
repository repository
repository
local remote other locals

9. Git protocols
file protocol file:///path/to/repo.git
/path/to/repo.gi
Git protocol git://server.com/path/to/repo.git
SSH protocol ssh://user@server/path/to/repo.git
user@server.com:path/to/repo.git
HTTP(S) protocol http://server.com/path/to/repo.git
https://server.com/path/to/repo.git

10. A bit about the now

11. How Monticello works
(in my mind)
.mcz
Cypress
+ Git
Monticello
black hole

12. Monticello problems
• file instead of objects
• chunk file format
• version tracking / ancestry by filename
• hard to understand

13. Cypress (FileTree)
meta data
source
package version categorization
commit tree blob

14. Cypress problems
• moves / renames not tracked
• very deep directory structures
• files instead of objects
• checked out version = only visible version
• hard to merge

15. Metacello
specification
platform + package versions
fixed loadable unit

16. Metacello problems
• complex implementation
• hard to maintain for big projects
• very steep learning curve

17. A bit on the future

18. How Monticello might work
Monticello
arbitrary
backend

19. Support for arbitrary
backends
Matthias Kleine,
Robert Hirschfeld,
Gilad Bracha
An abstraction for version
control systems
:
https://www.hpi.uni-potsdam.de/hirschfeld/publications/media/
KleineHirschfeldBracha_2012_AnAbstractionForVersionControlSystems_HPI54.pdf

20. Pharo 2 architecture
Metacello
Monticello
Monticello meta model

21. Current architecture
Metacello
Monticello
Monticello meta model

22. Possible future architecture
Metacello
Monticello
Ring
Git adaptor
Git bindings
Git

23. Possible future architecture
Metacello
Monticello
Ring
Mercurial Git adaptor
adaptor
Mercurial Git bindings
bindings
Mercurial
Git
? adaptor
? bindings
?

24. Model over matter (mostly)
Versioning model
Git adaptor Mercurial adaptor ? adaptor
commit
tree
blob
reference
changelog
manifest
filelog
tag
onesinglefile™

25. Why libgit2?
• well documented
• easy to understand
• fast response from community
• Git not required on host
• not maintained by us
• compiled to target platform
• no shell

26. Showing-off a bit
(Demo)

27. Some more bits
(random thoughts)

28. P2P backend
super node
peer

29. P2P backend: the good
• resilient
• independent
• don’t care about locality

30. P2P backend: the bad
• not visible to outsiders
• not searchable from outside
• maintained by the community (super nodes)

31. Revision meta data in Git
commit
tree
#printOn: - v0

32. Revision meta data in Git
commit
tree
#printOn: - v0
reference
tree
#printOn: - v1
#printOn: - v2
#printOn: - v3

33. Revision meta data in Git:
the bad
• not manageable through Git
• need extra tools
• information only available to select few
• overhead (who will look at it)

34. Revision meta data in Git:
the good
• collect data for research
• fine grained history
• don’t have to look at it if you don’t want to

35. A bit of a wrap up

36. A bit of a wrap up
• come a long way
• still a long way to go

37. A bit of a wrap up
• choice of storage backend
• better modularity (changing components)
• use existing solutions
• take load off community

38. A bit of a wrap up
• Git + abstractions: first step
• access to Git important (not just for revision control)

39. Acknowledgements
• Esteban Lorenzano
• Martin Dias
• Stéphane Ducasse
• Dale Henrichs
• Camillo Bruni

40. No more bits.
Thanks for your
attention