looks like a good master or PhD :) Interesting but need more cycle to think and play with it. 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
