On 24 February 2010 10:09, Stéphane Ducasse <[email protected]> wrote: > looks like a good master or PhD :) > Interesting but need more cycle to think and play with it.
Yes, there's a lot of things to think of. What i imagine is a distributed network of publicly available databases (repositories) where users could easily pick what to load , or update their images without ANY problems using a single mouse click. So, i, for instance could subscribe to Pharo-1.0-stable update stream and to Seaside 3.0-stable update stream. And at any moment i can click 'synchronize' and i'll get the exact match of my code in my own image with code, stored currently in those repos. > Stef > > On Feb 24, 2010, at 8:36 AM, Igor Stasenko wrote: > >> Few more words. >> >> Deltas/packages. >> >> All we need for Delta is to identify the starting point (an image >> state, from where you started changing it). In contrast to >> DeltaStreams model, where it tries to capture both an 'old' and 'new' >> state, so it can be reverted, we don't need it anymore, >> since we can directly see what was the image state before we applied >> the changes to it. Having all of the history preserved and tracked is >> very powerful thing! >> So, Delta only needs to reference to starting point (URI or some ID, >> which identifies it, and in case of need can be easily found on the >> web). >> >> What is cool about it? >> Suppose, initially, all images started from some release (say Pharo >> 1.0), so all users sharing the same sources/image state. >> Now what happens when you start forking or making changes? >> Users creating a deltas and storing them in the database , and their >> images now knowing that they are derived from Pharo 1.0 point but also >> has some changes stored in separate branch or 'fork'. >> >> Now, what happens if user wants to load the changes made by another >> user: system can easily find the common ancestral point (since all >> deltas knowing its own ancestral point). >> And there is two use cases: >> a) you doing a full synchronization with some remote source. This is >> useful, when all of us want to use the very same image. This is >> primarily a good thing for team-based development or Releases(R). >> b) you doing a partial synchronization (or merge) with remote source. >> In this case you creating own fork, which derived from , say Pharo 1.0 >> + some changes from user Foo, Bar, Baz etc and getting own, unique >> version of image. >> >> So no matter in what way you hacking/mixing the changes, you never >> lost track of the system history, which means that for any two images >> which derived from some common ancestral point we could could always >> automatically generate a diff between them. It means that no matter >> how far you went in your hacking - others could always load or >> cherry-pick your code! >> >> Packages? Since model, i describing, operating at lower granularity >> level (individual changes to methods/classes/doits), which means that >> any package can be represented as a set of those >> methods/classes/doits, there should be no problem >> integrating/interacting at a package level. >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
