[ANN] DeltaStreams release 0.1

Göran Krampe goran at krampe.se
Thu Nov 8 20:35:50 UTC 2007


(have a few minutes so I am throwing in my thoughts from the hip)

> Hi Matthew -
> Can you say a little more about the anticipated workflow with
> DeltaStreams?

Well, a little :). First of all - just like with changesets a Delta has
(at least not currently) no historic information in it.

The basic idea to amend this is to instead make it very fine granular and
specific (for example, modifying a method and creating it is not the same
change) combined with each change containing both the state AFTER and
BEFORE the change.

So... the most trivial way of using Deltas would be much like a ChangeSet
but with the added benefit of being able to have a validation step where
the Delta can check the image and tell if it will apply "clean" (the
BEFORE state of all changes are exactly as expected), "dirty" (the BEFORE
state is not as expected but the end result will still be "correct" in
some sense) or  "partial" (not all changes can be meaningfully applied).

In practice this would mean that a FIX from Croquet, recorded as a Delta,
when imported into say 3.10 could easily tell if the FIX is reasonable to
apply. And when applied and perhaps deemed to not work it can still be
fully reverted. :)

Still, this is not what you may be asking about - I presume you see all
the above - I presume you wonder about the "streams" part. I honestly
don't know yet but I would like to experiment with multiple streams
connected to projects, images, packages and even people - and combine this
with a publish/subscribe system so that you can easily discover streams -
subscribe to them etc.

If we try something like that I guess we immediately will hit upon the
next big NEED and that would be out-of-order apply - or in other words
"cherry picking". And I am hoping we can create

> I love what I see so far (it mostly looks like a version
> of change sets for the 21st century ;-)

Yes, Deltas themselves are intentionally exactly that I would say. This is
redundant I guess but I want them to be ROCK SOLID with full test coverage
(we have quite lots of tests) and covering all details (like for example
deal properly with class renaming). Also, since the default applier uses
SystemEditor it should work quite solidly (atomic etc) - but there are
still bugs in SE to iron out.

> but it is unclear to me how this
> integrates into the larger picture, with Monticello, images, versions etc.

It is definitely unclear to us too - but I intend to take the trivial
approach here: "one thing at a time". I am dead focused on making Deltas
work as intended - then we can tackle streams of them.

But if there are people interested in coming up with something around this
aspect - feel free to join up! For example, Giovanni Corriga is starting
some work on SM3 with Atom feeds etc, and without knowing exactly what he
is doing I would say it definitely relates.

Stephane also asked me about this btw, and I have no clear answers. I just
hope this new tool in our toolbox will be useful. ;)

> Any insights are greatly appreciated.
> Cheers,
>    - Andreas

Not sure if this post gave any, but hey. :) I want to keep things open so
that people are more interested in joining up.

And one important aspect here is cross-fork-compatibility - we are totally
committed to support all major Squeak "forks" and while on the subject -
what is your take on ToolBuilder in that respect? :)

regards, Göran

More information about the Squeak-dev mailing list