At the end of http://wiki.squeak.org/squeak/DeltaStreams , there is a section on proposed use cases. I don't know where they came from.
This is a really long reply. It is divided into two sections, and the first section has fouris made for easy scanning. I will put this in the wiki later.
Use cases and workflow
Note: If you don't want to read this whole section, the first paragraph of each numbered item has the summary, and the last paragraph the implementation status. The middle paragraphs contain the workflow detail.
But more personally, I think delta streams could solve 3 different, but related problems. I detailed the workflow of each problem.
In order of importance, delta streams can be used to:
Use case: finding differences between images using SystemEditor
reliably determine how various images are different and cherry-pick changes between them. The most obvious use for this is porting changes from squeak.org to croquet. It could also be used to port a lot of the internationalization work done in etoys and sophie to squeak.org. This is the most urgent use case I see, as the non-communication between squeak.org and croquet puts a low ceiling on what the two communities can produce together.
To do this, I envision being able to use the delta stream browser to "mock load" a change set or Monticello package made for one image into a system editor on another image. The browser would hilight the differences in all 5 browser panes, so that one could tell at a glance which classes and methods will be changed, and by how much.
This use case does not actually involve deltas or delta streams, only a UI and SystemEditor. However, I mention it because SystemEditor and DeltaStreams are evolving together, and my work on the delta streams browser has also resulted in a generic system editor browser, which allows viewing exactly what changes a particular edit will make once committed.
It is not yet supported, as we have no code yet to apply a change set or a package to a SystemEditor. The system editor browser (and its subclass, delta stream browser) still has bugs in which changes it shows, and does not yet do highlighting.
Use case: publishing cross-image update streams
Publish an update stream that can be safely applied on various images. This is what deltas and delta streams are really about.
Before one started coding up a patch, he would make sure that some delta was logging his changes, and perhaps set a few filters to make sure only "the right" changes are logged (for instance, it could only log changes to a particular set of packages, or only log comment changes or string changes). Then he would edit the system, and publish his change either independently, or as part of a group effort.
The reciever would try applying the delta. For classes and methods whose 'before' state matches what the reciever has, the change would be flagged clean. If they differed, they would be flagged conflict, and if they were missing, the changes would be flagged as orphaned. If the change seems to already have been applied, it would be flagged as 'already applied'. The reciever would be safely able to press the apply button without having to pre-check the change, as they will be informed of any problems before the change is comitted, without having to examine the patch at all beforehand. Orphans could be either discarded or handled smartly, perhaps be put in the MC1.5 orphanage, to be applied later when their parent arives.
Conflicts can always be handled manually, but the delta stream could instead publish different versions of changes for different image or package versions (like squeak map does), or mark which versions the delta works for (like the update stream does). A voting method has also been discussed, but not much.
This is not yet implemented. Currently, applying a delta just takes a big hammer and tries to make the changed classes and methods look like the end result of the delta. In other words, no sanity checking yet. I would like to get this working for release 0.2.
Use case: finding and reverting bugs
As with change sets, it is easy to determine which deltas changed which methods. Unlike change sets, however, the that and related changes can be quickly retrieved and reverted even if the change is not in the .changes file. Deltas are change logs, much like the .changes file.
Reverting is implemented and tested. Searching a single delta is partially implemented, but only minimally exposed via the UI (one can select all changes made to a particular class). Searching across deltas is not yet implemented.
Monticello integration
In 3.9 and 3.10, the update stream lost many of it's capabilities to both find the source of a bug and undo the change once found.
One idea I have to aleviate this difficulty is to log the saving of a MC snapshot in the delta as a note:
"This image just changed the version of package Kernel from version 4 to version 5"
When a recieving image encountered this, it would optionally check that the SystemEditor's package Kernel now matches the definition in Kernel-5.mcz. Upon commit, the version of the Working copy would be updated.
This would allow the delta stream to be searchable and revertable, while using MC to make unloadable entities
A disadvantage of this is that a project would have to decide whether it wants to use Monticello packages directly, or use packages in subordination to an update stream. Currently, only the release team would want to use MC this way, and most projects would continue using MC, rather than DeltaStreams, as their primary distribution mechanism.
Thus, using a delta stream would allow maintaining a cluster of inter-dependent packages, while using MC directly would be better for projects with well-factored or not very many packages.
