DeltaStreams!

Hi all!

I am glad for the responses so far to this idea. Some answers:

Jason:
Darcs? Nope. :) I love Darcs and have used it quite a bit. I also love
Mercurial. Lately I have come to the "conclusion" that magic like Darcs is
cool but can also be a pure PITA when stuff suddenly doesn't work. With
Deltas I want stuff to be very simple and you should not get surprises or
wonder why it did what it did etc. So the "smartness" here will be based
on other techniques than complicated historical analysis etc.

Keith:
SystemEditor? Yes, definitely! Loaded the latest and intend to use it!

Brad:
Started coding last night, not before my original post. :) See below.

Ron:
Yes, I think we need "standard packages" but I also think such a package
can have at least one official stream, possibly a few, and most probably a
few "non official" fix streams associated with it. So I don't see the
concept of Packages being replaced here - rather complemented. And sure,
if we end up with a collage of streams it might not make us any wiser, but
with a bit of careful design in how this will work I am hoping the
confusion can be minimized - as Andreas noted - we need to reference MC
snapshots etc somehow  to tie it all together. Ideas welcome!

Igor:
I don't agree in full regarding globals. IMHO it is not a solution to "get
rid of them". The globals are our common namespace. It is the basis for
our communication and interoperation. When I say Socket - you know what I
mean. And as you also pointed out earlier - analyzing globals is an
efficient basis for figuring out dependencies automatically. So I want to
keep them - possibly amended with my "prefixes improved" approach - but I
am not pushing that! DeltaStreams etc is meant to work in all major Squeak
forks and I don't see them all dumping globals any time soon. :)


Colin:
Nice to hear your views - I value them a LOT given your domain knowledge
here (MC/MC2). One thing I have come to appreciate after experience with
tools like MC and Darcs and now lately Mercurial (and earlier ChangeSets)
is that simplicity (Mercurial/ChangeSets) can sometimes beat smarts
(MC/Darcs) in *practice*. MC rocks in certain scenarios (a few devs
working on a common package) but does nothing for others (small fixes,
moving fixes in one fork into another). My wish is for a toolset which
leverages simplicity. It does not need to be *magically* smart, just a bit
smarter than ChangeSets - if it handles 90% of the cases REALLY GOOD and
fails in an EXPECTED way in the other 10% and then easily let developers
"hack it" - I will be very satisfied. I will try to sketch down use cases
so that we can explore together how these Deltas could/should behave - and
thus learn more - trying to keep an open mind to how
merging/conflicts/dependencies can be approached. And oh, I am using
SystemEditor of course. :)


Andreas:
Great to hear that you think it sounds useful! I agree, let's make it dead
simple so that we can get it operational soon. Working with MC - I agree,
also not sure what it will entail. :) The problem of "which deltas do I
have" and "which do you have" is indeed the "history problem" and normally
the basis for more advanced merging. I want to explore some use cases
before making Deltas smarter than what I described. I am hoping that the
combination of:

1. Making a Delta know *both* after and before state (like both the old
method source and the new for a simple method change).

2. Making it more granular and defined, like actually having a
AddedInstVarAction (and several more of course) instead of "class
definition was changed somehow".

... will enable enough smarts without having to go into too advanced
historical analysis.

Also - if the streams (both your own and the one it originates from) are
available we have lots of history. Again, great to hear you like the basic
idea!


I want to get this rolling in a loose team, I can't pull this one all
myself - we need to do it together. It will be seriously KISS, the
simplest working solution - and then evolve. So if you would like to help
out, email me, and I will add you as developer:

        http://www.squeaksource.com/DeltaStreams         (just created)

        Class prefix for code: DS

        PI: DeltaStreams

I also created a Swiki page for it, will stuff all info in there. I have
started writing class Delta and DeltaTest based on careful reading of
ChangeSet and reimplementing it fully, but *better* of course. :) I will
use latest SystemEditor. I will make first small snapshot later tonight,
first code sits at home in an image.

regards, Göran

PS. Apart from exploring using code I want us to discuss and write down
use cases. Please help with that!

>
> Igor:
> I don't agree in full regarding globals. IMHO it is not a solution to "get
> rid of them". The globals are our common namespace. It is the basis for
> our communication and interoperation. When I say Socket - you know what I
> mean.
That's the point!
And see the problem, we now saying Socket in Squeak-dev , Socket in
Croquet, Socket in here, Socket in there.
And this pattern tends to stay! So, why not just make it work?
Why not having packages be the only globals in the image. Why not
support package dependencies in image?

An example:
- i create a package which uses Collections, but since i don't like
something in it, i want to rewrite/hack stuff.
But instead of putting changes in Collections, i keep them in my
package. And since any references to Collection, Dictionary e.t.c in
my classes going through my package class table i finish with using my
modified versions and not interfere with other independent packages in
system which use Collections too.
At any time i can promote my changes upstream (if they found
acceptable), and this is just few clicks away. But before that i can
live with my own version of Collections without any risk of getting in
trouble when use different packages.

> And as you also pointed out earlier - analyzing globals is an
> efficient basis for figuring out dependencies automatically. So I want to
> keep them - possibly amended with my "prefixes improved" approach - but I
> am not pushing that! DeltaStreams etc is meant to work in all major Squeak
> forks and I don't see them all dumping globals any time soon. :)
>


--
Best regards,
Igor Stasenko AKA sig.

2007/8/15, Göran Krampe <[hidden email]>:
> So if you would like to help
> out, email me, and I will add you as developer:
>
>         http://www.squeaksource.com/DeltaStreams         (just created)


Why don't you globally enable write access to the repository? It will
ease adoption.

--
Damien Cassou