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