Hi Matthew -

Matthew Fulmer wrote:
> I wrote a long reply to your question, but I figured a more
> concise answer might be more welcome. I copied the long answer to
> http://wiki.squeak.org/squeak/DeltaStreamsUseCases

Thanks, this is pretty interesting.

> Here are three use cases I have in mind.
> 
> I would like to 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. This
> may or may not actually involve deltas and delta streams;
> SystemEditor and the UI I developed for it may be sufficient.

Yes, and I will point out that the main difficulty today is granularity. 
If you've ever tried to look through the 100 or so versions of the 
Morphic package in 3.9 you'll know what I mean ;-) Being able to do this 
*quickly* would actually be a major advantage for larger packages.

> I would also like to publish an update stream that can be safely
> applied on various images. This is what deltas and delta streams
> are really about. For instance, I would like to add some comments
> to core classes, and be able for everyone to see them with minimal
> hassle. This would require some automatic conflict handling to
> make it work without much trouble.

This goal may be a bit of a red herring, depending on how you think 
about it. The way in which it could make sense is if there were a 
package delta stream so that (for example) Seaside could have a common 
delta stream for all supported Squeak image versions. Outside of that I 
have my doubts about the usefulness of this approach - I cannot even 
begin to imagine applying changes (even from "harmless" streams) across 
the board automatically without some manual review and intervention.

> I also want the update stream to be very searchable and
> debuggable. The browser will automatically show you where in the
> update stream each method was changed. I would like that and more
> in the future, especially being able to revert changes.

Yup. This is all useful information we used to have with change sets. 
And it'll be great to have it back.

>> I love what I see so far (it mostly looks like a version of change sets for 
>> the 21st century ;-) but it is unclear to me how this integrates into the 
>> larger picture, with Monticello, images, versions etc.
> 
> 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 alleviate 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" 

Right. This is very similar to what I described in my other message. I 
think attributing deltas to have that information is a key property to 
ensure integration with other kinds of package management.

> When a receiving 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 revert-able, while using MC to make unloadable
> entities.

Exactly.

> 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. 

Or, make MC represent sequences of deltas.

> Thanks for asking questions. I hope DeltaStreams can be useful
> either on their own or as a step to something even better.

I think it's important to work out a few use cases that we understand 
enough to drive development to something useful. The interim step of 
producing both, delta as well as Monticello package may be a good way to 
address the first round of problems.

Cheers,
   - Andreas