[squeak-dev] trunk process sustainability

Eliot Miranda eliot.miranda at gmail.com
Fri May 3 21:52:10 UTC 2013


On Fri, May 3, 2013 at 1:04 PM, Chris Muller <asqueaker at gmail.com> 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).
>

I wrote code to coallesce this version info and posted it to the list a
couple of years back now.  I still have it if you're interested.
-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20130503/a81185e4/attachment.htm


More information about the Squeak-dev mailing list