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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
