Klaus, i would say this is another source version control system.

This bottom up approach is interesting but will not work. Squeakers will continue to use their preferred tools, not your specific browser.

Let's be more pragmatic and have a small incremental bottom up approach.

I see two solutions:
- store source code and history in image... I do not believe we should go in this direction even in compressed forms. We are rather making efforts to make images shorter... But you can have other opinion of course.
- continue storing source in external repositories (files, URL, NET  servers...)

In the later case, we could have many files instead of two (sources changes) and we should be able to have large files: conclusion: let's just change source code pointer encoding.

Using SmallIntegers (30 bits?) we can address 1GByte of space. More if bits are not encoded as file offset but as Oop on a server...

Using two SmallInteger, we have at least 60 bits, 1 ExaByte of data! Let's go for it (count how many compiledMethod are in your image... and you'll see this is not a drama).

Maybe we can have an encoding supporting 1 single SmallInteger for certain patterns (for example it can be sufficient for code stored in 'sources' file, 'sources' file could also be organised with an indirection table instead of using byte offsets...Given average source code length, that can save a factor between 10 and 100 i presume).

We should be able to extend source code being in several places in the future... (several files or URL or ...). So let use change encoding by splitting bits : 20 bits for sourceRegistry offset, 40 bits for file offset, or 30bits/30bits, or both (pattern starting with bits 0001 will be 20/40, all other 30/30 for example).

Then we have to create the SourceRegistry with objects able to handle source code stored in files, in compressed files, on the Net, with all necessary caching to reduce number of connections and design of the source code servers...

However, i would keep the principle of copying changes in the 'changes' file to recover easily in case of image crash, and commiting to another source would still be the responsibility of user, as is now.

Small details: make sure the FileSystem primitives can deal with huge offsets (and also underlying OS of course).

You see, nothing really new, nothing really difficult.
With just a little bit more reflexion we can go in this direction and that should be enough for a few years of development and future enhancements...

Nicolas

Klaus D. Witzel:
> 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
> 
> 
> 


________________________________________________________________________
iFRANCE, exprimez-vous !
http://web.ifrance.com