When you talked about the "database" it come to my mind an Envy Library....maybe something like that would help too.
Cheers Mariano On Wed, Feb 24, 2010 at 10:00 AM, Igor Stasenko <[email protected]> wrote: > 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 >
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
