On Thu, Nov 08, 2007 at 10:14:27AM -0800, Andreas Raab wrote:
> Hi Matthew -
>
> Can you say a little more about the anticipated workflow with DeltaStreams? 

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

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.

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.

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.

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

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.

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. 

> Any insights are greatly appreciated.

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

-- 
Matthew Fulmer -- http://mtfulmer.wordpress.com/
Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808