Squeak
  links to this page:    
View this PageEdit this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide
DeltaStreams
Last updated at 12:19 am UTC on 6 September 2007
This page describes a reimplementation of ChangeSets called Deltas. These Deltas are also meant to be distributed and handled in streams - thus the project name DeltaStreams.

The main motives for this project:
  1. Much improved ChangeSet functionality, should be able to fully replace them. A nice goal in itself.
  2. Making it easy to move fixes and enhancements to the base image AND to packages between branches and forks of Squeak.
  3. Making it trivial to publish, discover and subscribe to streams of Deltas.
  4. Making it trivial to publish, install and uninstall (revert) Deltas.

Thus it needs:
  1. A clean and fairly standalone implementation that should be easily adoptable by all Squeak forks/dialects. It will initially depend on SystemEditor for applying changes and the SystemChangeNotifier mechanism that was added to Squeak in... 3.7? (not sure)
  2. A smart but not TOO smart way to deal with merging and conflicts.
  3. A good robust distribution mechanism.
  4. Some kind of feedback system, probably added on top.

First post describing DeltaStreams and its rationale: http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-August/119471.html
Second post with some more feedback: http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-August/119531.html

Code

The code is currently developed in a vanilla Squeak.org 3.8.1-6747 image. It comes in two parts:
  1. Base fixes as a ChangeSet :) from SqueakMap: DeltaStreamFixes
  2. The DeltaStream package from SqueakSource: http://www.squeaksource.com/DeltaStreams
  3. The SystemEditor package from the same place. We are also synching it with the upstream (Colin's) repo for SystemEditor.

Features


Additional possible features


Related work


Delta vs ChangeSet

The differences so far are:
  1. Deltas have lots of tests.
  2. There can be multiple Deltas "logging" simultaneously instead of just one. We don't (redundantly) keep track of which ones they are outside of the standard notifier mechanism.
  3. A Delta uses a flat sequence (OrderedCollection) of so called Changes (formerly named "Actions", but "Changes" is a better name) to represent each actual fine granular code change. Each such change corresponds more or less with one notification from SystemChangeNotifier. In contrast ChangeSet uses a Dictionary of ClassChangeRecord instances grouping changes per class.
  4. Each Change records all its state including the state before the change, in an easily serializable way (it does not hold onto classes for example). Thus for example, a DSChangeClassCommentAction holds both the old and the new comment and the class name it refers to.
  5. Given the above each Change can create its corresponding anti Change. Applying the change and then its anti change should leave you with an image in its original state.
  6. Deltas know nothing about isolation features for Projects like ChangeSets do.
  7. Changes are more clearly defined, for example there are separate change classes for changing inst vars, changing class vars, changing the superclass etc etc, and not just a single "class def changed".
  8. Handles class renames gracefully - a class rename is an explicit change object.
  9. Normalization (removing redundant ones, addition followed by removal and so on) of Changes is an explicit operation and not done "on the fly" as ChangeSet does. This means that a Delta is a "true log" until you normalize it.
  10. A Delta has a UUID.
  11. A Delta has an attributes Dictionary to be able to handle more arbitrary info fields without requiring new code.
  12. ...and probably more we have missed.

The following is not yet commented by Göran (will ASAP):
(N.B. the stuff below, expect for some use cases, was added by Andy Tween)

Use cases


Bootstrapping

  1. decide on Delta file format
  2. create a minimal Delta loader
  3. manually create a Delta file containing the rest of the Delta system (system.delta)
  4. use Loader to load the Delta system from system.delta
  5. develop the Delta system, using only Delta files for persistence/merging/loading etc.? Eat your own dog food :)
? does this mean that squeaksource / monticello can't be used ?

Göran: I don't think bootstrapping needs to be so complicated. Currently DeltaStreams consists of a changeset tailored per Squeak version with some small base fixes - and the rest is an MC snapshot (+ SystemEditor). There is no reason to not use existing facilities to load DeltaStreams support into an image.
Andy: ok. I was thinking of how DeltaStreams could be used during development (of DeltaStreams), rather than how the support would finally be distributed once complete.

Delta File Format


Göran: I can easily imaging several formats but don't want to confuse things. Currently file format is the least of our worries in coding this. :) One thing is certain - we will never hardwire a specific file format into the code.
Andy: This ties in with the bootstrapping idea of using DeltaStreams during development of DeltaStreams. If they aren't used for development, and it is done with Monticello and changesets, then you are right, it doesn't need to be decided upon until later.

Method source

Chunk format (don't like. Would like method source to be unescaped)
What about terminating each method source with a marker specified in the method entry's header

e.g.

AddMethod class="Object" selector="xxx:yyy:" category="xxxx" timestamp="0101001" upTo="/n%"
xxx: a yyy: b
       "this is my method"
       ^42
%
AddMethod class="Object" selector="%" category="xxxx" timestamp="0101010" upTo="/n%%"
% anObject
      "this upTo has been chosen to be enough $% chars so that it does not appear anywhere in the method source"
      ^super
         % anObject
%%
AddMethod class="Object" selector="yourself" category="xxxx" timestamp="0101010" upTo="%"
yourself
       "we don't care about the Lf in the upTo terminator in this example"
       ^self%
AddMethod... etc.