Upload
esug
View
291
Download
0
Tags:
Embed Size (px)
DESCRIPTION
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
Citation preview
Contemporary source control for Pharo
This is the talk about Git.
ESUG, 2014-08-10 Max Leske
Overviewbackground
current state
the future
(Git)
(Git)
(Git)
A bit of history
Revision control systems
RCS (1982)
CVS (1990)
SVN (2000)
BitKeeper (1999)
Git (2005)Mercurial (2005)
Monotone (2003)
SCCS (1972) Random selection
distributed
centralized
Source control in Squeak and Pharo
RCS
CVS
DVS
Monticello
Monticello 2
Greatly exaggerated
A bit about Git
“The stupid content tracker from hell”
Git objectsreference
commit
treetree
blobblob blob
tree
Git repositories
local remote other locals
Synchronization point (usually)
repository repository
repository
repository
Git protocolsfile protocol file:///path/to/repo.git
/path/to/repo.gi
git://server.com/path/to/repo.gitGit protocol
ssh://user@server/path/to/repo.gitSSH [email protected]:path/to/repo.git
http://server.com/path/to/repo.gitHTTP(S) protocolhttps://server.com/path/to/repo.git
A bit about the now
How Monticello works (in my mind)
.mcz
Cypress + Git
Monticello
black hole
Monticello problems
• file instead of objects
• chunk file format
• version tracking / ancestry by filename
• hard to understand
Cypress (FileTree)
source
meta data
package version categorization
commit blobtree
Cypress problems• moves / renames not tracked
• very deep directory structures
• files instead of objects
• checked out version = only visible version
• hard to merge
Metacellospecification
platform package versions+
fixed loadable unit
Metacello problems
• complex implementation
• hard to maintain for big projects
• very steep learning curve
A bit on the future
How Monticello might work
Monticello
arbitrary backend
Support for arbitrary backends
Matthias Kleine, Robert Hirschfeld, Gilad Bracha
https://www.hpi.uni-potsdam.de/hirschfeld/publications/media/KleineHirschfeldBracha_2012_AnAbstractionForVersionControlSystems_HPI54.pdf
An abstraction for version control systems:
Monticello
Metacello
Pharo 2 architecture
Monticello meta model
Current architecture
Monticello
Metacello
Monticello meta model
Possible future architecture
Git
Git bindings
Git adaptor
Monticello
Metacello
Ring
Mercurial
Mercurial bindings
Mercurial adaptor
Git
Git bindings
Git adaptor
Possible future architecture
Monticello
Metacello
Ring
?
? bindings
? adaptor
Model over matter (mostly)Versioning model
commit tree blob reference
changelog manifest filelog
tag
onesinglefile™
? adaptorMercurial adaptorGit adaptor
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
Showing-off a bit(Demo)
Some more bits(random thoughts)
P2P backend
super node
peer
P2P backend: the good
• resilient
• independent
• don’t care about locality
P2P backend: the bad
• not visible to outsiders
• not searchable from outside
• maintained by the community (super nodes)
Revision meta data in Git
commit
tree
#printOn: - v0
Revision meta data in Git
commit
tree
#printOn: - v0
tree
#printOn: - v3
#printOn: - v2
#printOn: - v1
reference
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)
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
A bit of a wrap up
A bit of a wrap up
• come a long way
• still a long way to go
A bit of a wrap up
• choice of storage backend
• better modularity (changing components)
• use existing solutions
• take load off community
A bit of a wrap up
• Git + abstractions: first step
• access to Git important (not just for revision control)
Acknowledgements• Esteban Lorenzano
• Martin Dias
• Stéphane Ducasse
• Dale Henrichs
• Camillo Bruni
No more bits.Thanks for your
attention