> 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.

I would really like to have a distinction between Doit and  
definition. Because this way we could build much clever tools. In VW  
classDef are not doit and you can eliminate doits when you want to do  
a replay all.

Do I understand correctly by saying that this would be a component  
that could be put between the sources/changes and MC for example.

> -------------------------------
>
> 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
>
>