Posted by Göran Krampe on Mar 06, 2009; 10:51am
URL: https://forum.world.st/What-about-ifNotNil-and-ifNotNilDo-tp1309537p1309542.html

Hi all!

Marcus Denker wrote:
> On 22.02.2009, at 19:31, Marcus Denker wrote:
> As soon as there are changesets that touch the same code, it starts to  
> get *very* messy.

Which is one of the things that Deltas (in DeltaStreams) tries to deal
better with.

Let me explain quickly for those that do not know the idea:

A Delta is "ChangeSet improved". It is an *ordered* list of changes
instead of a Set. So ChangeList would be another good name. :)

But that is not all it is, it also:

- Models each kind of change using a unique class in much finer detail.
Like "AddInstVarChange" for example. This creates the potential to be
much "smarter".

- Each change captures the "before state". This is very important - it
doesn't only hold the "new method" but also the old one. (a diff could
of course also work, that is just implementation details)

- A Delta can be loaded into the image *before* it is installed. Thus
you can operate on a Delta and analyse it before applying it. This is
VERY important.

- A Delta is *fully self contained*. It does not just "point to a
method" like ChangeSet does. Thus, no matter how much the image changes
- the Delta is totally isolated and totally independent of the image.

- It can also be unapplied.

Now... one use case that I wanted to be able to do with Deltas is to be
able to load 100s of Deltas into an image (remember - they are not
*installed* when only being loaded) and then *analyse* them in tons of
ways like for example:

- Can they be "cleanly applied"? One definition of "clean" is that the
"before state" matches the image.

- Can they be "dirtily" applied? One definition of "dirty" is that the
before state does NOT match, but we can still apply it. Given say a
Delta with a single method change - and the whole class is missing -
then we can't apply it at all. But if the class exists - but with a
DIFFERENT version of the method than the captured "before state" - we
can apply, although possibly overwriting other changes.

Since Deltas can be applied and unapplied we can start playing with
"patch queues" like Mercurial and other systems have. So let's say you
load 42 Deltas from some strange places - perhaps totally independent of
each other. You look at them, the tool tells you that well, 37 can be
cleanly applied "one by one" and 2 can be dirtily applied, and 3 are
dead ducks.

Ok, so you tell the tool to fine, group them by developer and sort them
chronologically and analyze them in groups one by one. Then it might say
that, sure first 2 groups from Marcus comprising 23 Deltas would apply
fine - then it get's stuck on one of the dead ducks in group 2 from
Andreas :).

So you feel brave and tell the tool to fine - apply those first 2 groups
of 23 (in total) so we can run tests being touched by those 23. The tool
should be able to figure out a reasonable Set of tests that are affected
given classes being modified and referenced by tests. Perhaps some tests
turn red, so you tell the tool to unapply Deltas *one by one* (until the
tests are green again, perhaps it ends up with 17 applied but the 18th
caused the problem. It could even do a binary search. :)

The dead ducks may be because of class renames. Tool could again try to
find the right class for you.

I am blabbering, but as you can see having working Deltas could enable a
whole *range* of interesting tools that can operate *regardless* of history.

Just writing about it makes me want to pick it up again where we left
off. And no, this is not purely hype-code - a lot of stuff actually
works today, including unapply.

regards, Göran


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project