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