[Pharo-project] Source code management - my vision. (Was: Re: Why apackage management system)
siguctua at gmail.com
Wed Feb 24 02:36:11 EST 2010
Few more words.
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
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.
Igor Stasenko AKA sig.
More information about the Pharo-dev