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