Nicolas

thank you for taking the time for a response.

On Wed, 26 Jul 2006 20:55:44 +0200, you wrote:

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

I did not have version *control* in mind but yes, scs could be used for  
such ancient concepts (used them for > 30 years, quite an experience).

No, I was lead by the aim for more collaborative features (hmm, since  
there are none in Squeak, should I say for *at least* one or two  
collaborative features).

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

No specific browser, just colors in the list views of the existing  
browsers. One or two additional items on the context menus, that's all  
about it :)

In my imagination you're running 2-3 Squeak images at the same time (on  
your 2-4GB memory / 2-4 GHz quadruple core notebook, what else would you  
like to to with your hardware?).

One image in which you do all the "abstract" work, incl. docs (hopefully  
;-) the second image for the hard stuff (compile&debug the new project) in  
the 3rd image you do all the testing; and (perhaps) in the 4th you hunt  
the nasty bugs left over from the previous project(s).

These images all work with the same source code subsystem, integrity  
guaranteed. And if you do a mistake in one of the images, the others will  
not be infected. Now how about this?

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

The source code pointer is only bytes. If a quick solution is needed, why  
not add just one more byte and take a breath until the then 256 fold limit  
is reached?

Nicolas, as said above I really appreciate you take care for a response  
BUT aren't you comparing apples (new source code subsystem) with oranges  
(one or two byte lengthening of a pointer).

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

This sounds easy but relies on the current Changes mechanism which is  
rotten in the image. Isn't it time to overhaul the framework instead of  
attaching new pneus with new rims? Buying new rims and pneus from Ferrari  
(they're just around the corner here :) doesn't buy you a Ferrari ;-)

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

"to another repository"?

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

Sure, must be verified in advance.

> You see, nothing really new, nothing really difficult.

Absolutely; adding one more byte to the length of the current source  
pointer is a matter of minutes (followed by roughly the time it'd take for  
#condenseChanges and friends).

But will that byte add you productivity, flexibility, reliability, choice,  
collaborative facilities?

> With just a little bit more reflexion we can go in this direction and  
> that should be enough

What a different *one* byte makes :)

> for a few years of development and future enhancements...

No. Comparing just the capacity (in bytes) is about quantity, and quality  
would be ignored (once again, Marcus, you're right with your critique).

The existing source code subsystem is for a one man show, you and your  
.changes file (regardless where it's stored).

No collaborative work backed by a repository possible, except you do it  
all manually: on a COMPUTER, of course!

/Klaus

> Nicolas