[squeak-dev] Re: Our process, some loose ideas regarding DS + MC

Igor Stasenko siguctua at gmail.com
Sat Aug 15 23:08:53 UTC 2009


2009/8/16 Andreas Raab <andreas.raab at gmx.de>:
> Göran Krampe wrote:
>>>
>>> Simply the question of where/how DS are stored. Monticello has
>>> repositories that store full source for a package. As a consequence packages
>>> are large, but they allow you to see what's different in your image, what a
>>> patch does, tracking history etc. You can agree on a place and say "this is
>>> THE repository for package X" etc. I'm wondering where DS stand with regards
>>> to these issues.
>>
>> Since the Stream part is not yet started I am all ears. But apart from the
>> obvious fact that Deltas can serve the same roles as Changesets can (only
>> better), I was envisioning chronological "streams" (as in continuous flows)
>> of Deltas associated with individual developers, forks, packages and
>> branches of packages etc.
>
> A thing to keep in mind is that there is huge value in having a definitive
> version of the code that you can compare against somewhere. Being able to
> say "oh, these are my local changes" is a large part of what makes working
> with MC superior to working with change sets. So it would be really useful
> if one could say "compared with this repository, you have applied delta x,
> y, and z, and in addition you have modified methods foo and bar".
>
>>> That's *very* useful. One of my favorite features when using MC is that
>>> it can tell us if there is a conflict in a merge and that this method
>>> requires special attention. If DS can do something similar by telling us
>>> that the base version of a method is different from when the DS was created
>>> this will be hugely helpful.
>>
>> This is in fact the *core idea*. The idea came about after watching Linus
>> thoughts on git and to think about how MC and most SCMs work. They all get
>> their "merge magic" from extensive knowledge of history to a common base.
>> But that is something we don't have between forks.
>
> Why not? Actually we do. MC will search any repository you add and if it
> finds any common ancestor in any of the repositories it will use that. I've
> done some pretty extensive merges that way and the only thing MC lacks in
> this area is explicit support for cherry-picking (i.e., to accept or reject
> changes even when they don't conflict).
>
>> Thus, could we get 80% of magic using simpler tricks? The trick is to let
>> the Changeset contain more info - especially info about the "before" state.
>> This of course both enables unapply, but more essentially it enables much
>> smarter apply-logic.
>
> Interesting. I had thought that keeping the stamp or a hash would be enough
> but you're right, having the actual previous version does allow you to
> trivially revert to it. Very clever.
>
>> Also, a Delta can do other smart things since it has captured class
>> definition changes in more detail - say you add an ivar "c" and when it
>> checks the destination image it finds other additional ivars but no "c" -
>> then it can merge by just adding "c". Nice eh? :)
>
> Nice. But more a sign of weakness in Monticello ;-) But it's definitely a
> good idea since this can cover additions that come from "other" deltas.
> Which reminds me: Where are the deltas stored and how big is the space
> overhead for keeping them?
>
i think most common overhead is 2x more space comparing to analoguous
changeset record, since you have to keep 'before' version in addition
to 'after' version. And most common change is changing the method(s)
source a little bit.

Oh, and did Goran mentioned that Deltas could be also 'compressed' in
same way as changeset?
I mean
you having versions A -> .... -> Z
in uncompressed form,
but surely you may decide to obliterate intermediate versions (....),
so final delta will be
A -> Z
you losing ability to roll back to any intermediate version, but you
still can roll back/forward between A<->Z

> Cheers,
>  - Andreas
>
>



-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list