Contemporary source control for pharo


Published on

Title: Contemporary source control for Pharo
Speaker: Max Leske
Wed, August 20, 2:30pm – 3:00pm

Video Part1:
Video Part2:

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


Bio: Max Leske is a master student of University of Bern and working with

Published in: Software
1 Comment
  • Video Part1:
    Video Part2:
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Contemporary source control for pharo

  1. 1. Contemporary source control for Pharo This is the talk about Git. ESUG, 2014-08-10 Max Leske
  2. 2. Overview background current state the future (Git) (Git) (Git)
  3. 3. A bit of history
  4. 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. 5. Source control in Squeak and Pharo Monticello 2 Monticello DVS CVS RCS Greatly exaggerated
  6. 6. “The stupid content tracker from hell” A bit about Git
  7. 7. Git objects reference commit tree tree tree blob blob blob
  8. 8. Git repositories Synchronization point (usually) repository repository repository repository local remote other locals
  9. 9. Git protocols file protocol file:///path/to/repo.git /path/to/ Git protocol git:// SSH protocol ssh://user@server/path/to/repo.git HTTP(S) protocol
  10. 10. A bit about the now
  11. 11. How Monticello works (in my mind) .mcz Cypress + Git Monticello black hole
  12. 12. Monticello problems • file instead of objects • chunk file format • version tracking / ancestry by filename • hard to understand
  13. 13. Cypress (FileTree) meta data source package version categorization commit tree blob
  14. 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. 15. Metacello specification platform + package versions fixed loadable unit
  16. 16. Metacello problems • complex implementation • hard to maintain for big projects • very steep learning curve
  17. 17. A bit on the future
  18. 18. How Monticello might work Monticello arbitrary backend
  19. 19. Support for arbitrary backends Matthias Kleine, Robert Hirschfeld, Gilad Bracha An abstraction for version control systems : KleineHirschfeldBracha_2012_AnAbstractionForVersionControlSystems_HPI54.pdf
  20. 20. Pharo 2 architecture Metacello Monticello Monticello meta model
  21. 21. Current architecture Metacello Monticello Monticello meta model
  22. 22. Possible future architecture Metacello Monticello Ring Git adaptor Git bindings Git
  23. 23. Possible future architecture Metacello Monticello Ring Mercurial Git adaptor adaptor Mercurial Git bindings bindings Mercurial Git ? adaptor ? bindings ?
  24. 24. Model over matter (mostly) Versioning model Git adaptor Mercurial adaptor ? adaptor commit tree blob reference changelog manifest filelog tag onesinglefile™
  25. 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. 26. Showing-off a bit (Demo)
  27. 27. Some more bits (random thoughts)
  28. 28. P2P backend super node peer
  29. 29. P2P backend: the good • resilient • independent • don’t care about locality
  30. 30. P2P backend: the bad • not visible to outsiders • not searchable from outside • maintained by the community (super nodes)
  31. 31. Revision meta data in Git commit tree #printOn: - v0
  32. 32. Revision meta data in Git commit tree #printOn: - v0 reference tree #printOn: - v1 #printOn: - v2 #printOn: - v3
  33. 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. 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. 35. A bit of a wrap up
  36. 36. A bit of a wrap up • come a long way • still a long way to go
  37. 37. A bit of a wrap up • choice of storage backend • better modularity (changing components) • use existing solutions • take load off community
  38. 38. A bit of a wrap up • Git + abstractions: first step • access to Git important (not just for revision control)
  39. 39. Acknowledgements • Esteban Lorenzano • Martin Dias • Stéphane Ducasse • Dale Henrichs • Camillo Bruni
  40. 40. No more bits. Thanks for your attention