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