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
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
stéphane ducasse wrote: [lots of stuff snipped]
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.
I would like to make a point that Doits should not be a separate concept: I am aware that it is common practice to have Doit methods in workspaces, for example. For a long time now, I and my colleages have stored all the Doits as methods in a Script class made for this purpose.
The rationale is that Doits are part of the code, and should be treated the same by the CM system (Envy in our case).
This works out very well. I especially like the fact that refactorings reliably catch the Doits as well, since they are normal methods.
I cannot see any disatvantages from this approach, and it keeps things really simple, imho.
Thanks, Wolfgang
Hi Wolfgang,
I share your view on doIt's, simply because they survive fileOut's and fileIn's better and are kept in the context where they belong to.
What do you do with doIt's like "Smalltalk garbageCollect", e.g. those which are not related to project work?
/Klaus
On Fri, 28 Jul 2006 10:54:06 +0200, Wolfgang Eder edw@generalmagic.at wrote:
stéphane ducasse wrote: [lots of stuff snipped] I would like to make a point that Doits should not be a separate concept: I am aware that it is common practice to have Doit methods in workspaces, for example. For a long time now, I and my colleages have stored all the Doits as methods in a Script class made for this purpose.
The rationale is that Doits are part of the code, and should be treated the same by the CM system (Envy in our case).
This works out very well. I especially like the fact that refactorings reliably catch the Doits as well, since they are normal methods.
I cannot see any disatvantages from this approach, and it keeps things really simple, imho.
Thanks, Wolfgang
Klaus D. Witzel wrote:
Hi Wolfgang,
I share your view on doIt's, simply because they survive fileOut's and fileIn's better and are kept in the context where they belong to.
What do you do with doIt's like "Smalltalk garbageCollect", e.g. those which are not related to project work?
i just checked: most methods (there are ca 240) relate to some task (e.g. packaging, clearCaches, ...) or some project (mp3playlists, ...)
of course, since it's regular methods, i sometimes to some refactoring/cleanup.
one more thought on this topic: you can use class and instance variables in your scripts; (i use class vars for stuff i like to stick around, inst vars i never needed). this is much less obscure that workspace variables imho
cheers, wolfgang
/Klaus
On Thu, 27 Jul 2006 10:22:09 +0200, stéphane ducasse ducasse@iam.unibe.ch wrote:
Klaus wrote:
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).
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.
Sure. In my huble opinion there must be a backpointer for each and every class,trait definition like it is for method definitions and class comments. Alternately we can provide - http://www.sticky-notes.net/ together with all Squeak distributions (putting the [|] logo on them as default) such that the developer can write down the previous definition in case they are going to be changed ;-)
Do I understand correctly by saying that this would be a component that could be put between the sources/changes and MC for example.
I think it'll work on the sources/changes interface (and unify both files). If MC & friends use that interface, fine. I have as yet not completed analysis of what interface MC and SM (the prominent examples) use from the "base" image. I'd appreciate someone shares the respective requirement def's (of MC and SM), that'd save me quite some time.
/Klaus
squeak-dev@lists.squeakfoundation.org
-
Klaus D. Witzel -
stéphane ducasse -
Wolfgang Eder