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