[squeak-dev] trunk process sustainability

Levente Uzonyi leves at elte.hu
Fri May 3 23:16:21 UTC 2013


I uploaded 2 packages related to this to the Inbox. Together they speed up 
the update about 3-4 times if there are no changes. Further improvements 
are possible, though these don't help with the problems you described.


Levente

On Fri, 3 May 2013, Chris Muller wrote:

> We need to be able to develop unrestricted, whether its short and fast
> rapid-fire one-line commits or larger, slower, deliberated
> enhancements.
>
> We're not in trouble yet but eventually we'll need to address our
> trunk process implementation limitations.  We've touched on it before;
> for the FileBasedRepository limitation, Levente had an idea about
> linking to an archive repository.  Perhaps the recent changes to
> RepositoryGroup help facilitate this too.  Also there is always
> GemStone-based SS3 which may not have issues with large scale thanks
> to being indexed in a DB.
>
> That leaves the ancestry issue, in the model where we have:
>
>  aVersionInfo
>      'ancestry' -> anArray(aVersionInfo aVersionInfo)
>           1-> aVersionInfo
>               'ancestry' -> anArray(aVersionInfo)
>                  ....
>            2-> aVersionInfo
>                  ...
>
> all the way to the first version, including all comment history.
> mcz's still get bigger and bigger on disk but was thinking about a
> MCProxy (or maybe just MCVersionInfoStub), which could be used to
> proxify the tree in memory at least, and bringing it in on demand from
> its original repositoryGroup if necessary (e.g., during save and if
> history was requested).
>
>


More information about the Squeak-dev mailing list