This document discusses storing code change history in Smalltalk projects. It notes that current approaches store change history in .sources and .changes files, but these are not shared between images and not thread-safe. It proposes using the Soil library to store a transaction log with old code versions that is shared between images and thread-safe. It also mentions the Epicea library for modeling code changes but notes it is slow. Finally, it suggests improvements like indexing senders/implementors, full text search, and storing the full code history.

1. Soil and
Pharo
Marcus Denker
Inria Evref

2. Sources/Changes
• Every compiled method has a pointer
to .sources/.changes
• Stored in the last 5 bytecodes
• Every entry is an o
ff
set in the
fi
les

3. Need: Not in Image
• .sources is 40MB
• Would be a large chunk of the image
• (But: Perm Space changes the picture)

4. Need: History
• Having a per-accept history is nice
• Does not depend on commits to git

5. Need: Transaction Log
• Pharo crashes and you have to saves the image or stored
the code in git
• All accepted methods / class comments / class
de
fi
nitions are in the .changes
• Replay is possible

6. Current problems
• Can not be shared by images, but can not be locked
either
• Not thread safe
• Very simple caching
• SLOW!

7. Soil
• Has transaction log
• Supports accessing old versions
• We could just store a Soil Object Pointer per
CompiledMethod
• Thread safe

8. Epicea
• Higher level Code Change model
• Stored in text
fi
les
• Slow !

9. Indexing
• We do not use indexing
• Senders
• Implementors
• Full text search

10. Resources
• We store some data as Base64 Encoded strings
• Even as method comments (!!)
• abuse the .sources/changes am object store…

11. Why not …?
• store the whole history of the code ?
• e.g
fi
nd deprecation transforming methods
• store at the AST granularity?

12. Demos next ESUG!