New source code subsystem
Klaus D. Witzel
klaus.witzel at cobss.com
Wed Jul 26 14:56:16 UTC 2006
List,
I put together what I think is relevant for a new source code subsystem
and, if I'm mistaken or have overlooked one of your recent suggestions
and/or requirements, please do not hesitate and say so.
What follows is not intended as a replacement for MC or SM, rather the new
subsystem should be as independent as possible. If you load something with
MC, the new subsystem can treat it like any other contribution (more about
contributions later).
Trying to keep preliminaries as short as possible, we have as
organizational elements (for the sake of discussion): system categories,
classes, message categories and methods. The unit of source code "entity"
we consider to be a unit of change belongs to one of these elements. We
can add, replace, rename and delete. We have not only methods, but also
DoIt's (definitions, organizational, etc) to take into account. And let's
say that the browser is our tool, just to keep it simple here.
-------------------------------
At the time an image is distributed, it is supposed to be in sync (not
necessarily *full* sync) with its respective source code subsystem. So
when you open a browser, all entities are colored black on white, and my
story begins.
When you want to *observe* a certain area of the source code subsytem, you
put the respective entity (item from here on) onto your watchlist (cmd+ if
you like) from where the item gets the color blue. After putting a class
onto your watchlist you get all its message categories and methods blue;
un-watch those (sub)items which are of no interest to you; etc for other
organizational levels.
When you do a *change* to a blue colored item, its new source is
contributed to the source code subsystem (from here on scs for short) and
the item is colored green in your browser. If later somebody else
contributes a change to the same blue item, it gets the color yellow in
both browsers.
And if an entity you have in your image cannot be *matched* with the scs,
it is colored red.
As is tradition, if you don't save your image before the next crash, all
this coloring information is lost, and you are back to black and white.
The scs does NOT know the state of your image.
-------------------------------
A contribution to the scs either has a predecessor or else it is new (to
the scs). Let's say three developers make contributions to the same blue
item, then we arrive at three branches (and the three browsers color the
respective item yellow). It is up to you to accept one of these branches,
but you are no forced to do so. An accepted branch is colored green (it
will turn yellow when the next contribution relative to it arrives).
-------------------------------
By chasing the predecessor it is always possible to roll-back an item (or
a group of items), this is independent of the coloring I used for
illustration. The same "backwards" information is readily available for
analyzing the complete history of an item, including all unaccepted
branches.
-------------------------------
Doing this into the other direction (roll-forward) depends on which
branches where accepted. At any point in time, accepted branches represent
a "cut" in the scs.
-------------------------------
If you work alone on a project, you'll never see any yellow colored item,
unless you revert a change (because the dismissed becomes an unaccepted
branch). For people who are used to make small incremental changes, a
preference tells whether or not every change is treated as a branch or
else is to be consolidated until you do a "big save" to the scs. The
latter requires, I think, a local buffering scs on your harddisk (or on
your local area server).
-------------------------------
The amount of conversation between browser and scs is small, the browser
only has to ask for colors (one byte answer per item) for those items it
shows *and* which are on your watch list. But if you want to see more
(like, for example, all branches of an item), more data will have to
travel.
-------------------------------
It's now time for me to sit back and relax :-)
/Klaus
More information about the Squeak-dev
mailing list
|