On 9 nov. 07, at 07:18, Andreas Raab wrote:

> 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 should be one of few crazy that did that. So unfortunately I know  
what you mean :)
and I have the impression that using deltastreams for update that  
version packages on demand.
We could have a change that says please version package X.
I hope to be able to work on faster MC loading but time time.... and  
it should be really stable and robust so we will see.

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

yes or having a change element that is version package X after that  
bunch of change elements.
>
>> 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.

I do not really know if MC representing sequences of deltas will save  
the following problem (but I suspect): we got really problems with  
3.9 when a change was cutting two packages (we mentioned that in our  
postmortem analysis), our problem was that it was not easy to know  
(without doing a diff between the two
config files) which changes have to be removed together (for example  
when we had to roll back and complex changes touching multiple  
packages). This
was an information that we really missed.
>
>> 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
>
>